Looks like unnecessary mapping of capability
Stefan Kalkowski
stefan.kalkowski at ...1...
Thu Jan 31 20:20:05 CET 2013
Hi Jaeyong,
On 01/31/2013 03:59 AM, jaeyong yoo wrote:
>> When waiting for IPC you can specify capability indices, which will
>> contain capabilities passed by the sender. If the capability indices you
>> specified contain still valid capabilities, they will nevertheless get
>> overwritten. In Genode, the message buffer object "Msg_buf" has some
>> capability indices used to hold received capabilities. Before receiving
>> new ones, already received capabilities are duplicated via "l4_task_map".
>
> Thanks for the answer.
> I would like to check that I understand correctly with the following
> example.
> Please stop me if I am going somewhere wrong.
>
> We can consider a thread waiting for an IPC with the following rcv_buf:
>
> rcv_buf {
> [cap: 0x13000(dst), 0x002f(local_name)]
> some buf;
> }
Well, I suppose that's the point where things get wrong ;-).
I fear you're still mixing up Genode and Fiasco.OC abstraction layers.
Whereby, I've to admit the topic is quite complicated.
On the kernel API level a capability is just an address value (denoted
as "dst" above). In Genode a capability consists of the kernel
capability and an additional value (denoted as "local_name"). When
transfering a Genode capability via the kernel's IPC mechanism, you
transfer the "local_name" as a normal value. Whereby the kernel
capability is handled separately.
When waiting for, or sending a message via the kernel's IPC primitives,
you've to describe what kind of items you'll send or receive via the
UTCB (user-level thread control block). Therein you describe how many
normal data values, memory mappings, or kernel capability mappings,
you're willing to receive or to send.
Imagine a thread wants to receive a single capability. Then it has to
tell the kernel where in its task's capability space the received item
should end up. The kernel isn't responsible for allocating/freeing items
in the capability space. The same way like most microkernels aren't in
authority to organize the memory spaces, but let the userland organize
their virtual memory themself. So lets say the thread wants the
capability to end up at 0x13000 in its capability space. Then it would
prepare its UTCB e.g. like the following:
l4_utcb_br()->br[0] = 0x13000 | L4_RCV_ITEM_SINGLE_CAP;
before it triggers an ipc_wait syscall. If on the other side the sender
put a capability into its UTCB in an appropriated manner, the kernel
will now associate the kernel object behind the capability to be send
with address 0x13000 in the capability space of the receiving thread.
That means the transfered capability ends up at 0x13000. If the thread
wants to invoke the received capability it will use this address for it.
The "local_name" value, which is only meaningful for the Genode
abstractions, has to be transfered like every other normal values, like
e.g. opcodes, strings, etc.. These values are stored in a different area
of the UTCB. The kernel doesn't care about it.
After successfully receiving an IPC on the kernel level, within Genode
we transfer the values out of the UTCB of the thread, into the "Msg_buf"
object - a Genode abstraction. This message buffer again consists of
normal data, hold in a byte array, and kernel capability indices, hold
in a corresponding array. Now, if you unmarshal a Genode capability out
of such a message buffer object, you will take the "local_name" value
out of the normal data array, and the "dst" value out of the capability
indices array,and construct a Genode capability out of it.
I've to admit, reality is even more complex, but this is the reasonably
neat story. If you want to have a look, how Genode capabilities are
constructed out of the message buffer in more detail, please have a look
at: base-foc/include/base/ipc.h
I think this whole topic would be better off in a separate article.
Nevertheless, I hope my explanatory notes are more enlightening than
confusing.
Best regards
Stefan
>
> The thread receives an IPC call and the rcv_buf becomes the following:
>
> rcv_buf {
> [cap: 0x14000, 0x002f] // <--- overwritten to 0x14000.
> some buf;
> }
> And, 0x14000 and 0x13000 is mapped by l4_task_map.
> And, the thread who waits for the IPC call (who originally created
> 0x13000) uses
> the capability index 0x13000 as usual.
>
>
> Regards,
> Jaeyong
>
> On Wed, Jan 30, 2013 at 7:34 PM, Stefan Kalkowski
> <stefan.kalkowski at ...1...
> <mailto:stefan.kalkowski at ...1...>> wrote:
>
> Hi Jaeyong,
>
> On 01/30/2013 02:20 AM, jaeyong yoo wrote:
> > Hello! Genode,
> >
> > From time to time, I saw something like this:
> >
> > l4_task_map(L4_BASE_TASK_CAP, L4_BASE_TASK_CAP,
> > l4_obj_fpage(A.dst(), 0, L4_FPAGE_RWX),
> > B.dst() | L4_ITEM_MAP);
> >
> > I think it looks like a unnecessary mapping, because rather than
> > mapping, we can just copy the capability like this,
> > A = B.
>
> No, that's not the same. Moreover, it has to be "B = A" in your example.
>
> The "l4_task_map" call above, creates a duplicate of the capability
> referenced by "A.dst()" to "B.dst()". The value given by "dst()" is an
> index into the capability name space of the task - in the following
> shortly titled as capability index. You cannot modify the capability
> name space in user mode. All changes to that space are done explicitly
> via the "l4_task_map" syscall, or implicitly by sending a capability
> mapping via IPC.
>
> The second example is simply an assignment, where A and B will reference
> the same capability index in the end. Moreover, the reference counter in
> Genode's capability will be increased. Look at
> "base-foc/include/base/native_types.h" for the definition of the
> capability class for Fiasco.OC.
>
> Normally, we simply use the simple assignments when passing around
> capabilities by value. But in some rare situations it is necessary to
> really duplicate a capability index.
> When waiting for IPC you can specify capability indices, which will
> contain capabilities passed by the sender. If the capability indices you
> specified contain still valid capabilities, they will nevertheless get
> overwritten. In Genode, the message buffer object "Msg_buf" has some
> capability indices used to hold received capabilities. Before receiving
> new ones, already received capabilities are duplicated via
> "l4_task_map".
>
> Regards
> Stefan
>
> >
> > Since I'm feeling like I miss something here, could you tell me the
> > difference between two of them?
> >
> > Best regards,
> > Jaeyong
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_jan
> >
> >
> >
> > _______________________________________________
> > Genode-main mailing list
> > Genode-main at lists.sourceforge.net
> <mailto:Genode-main at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/genode-main
> >
>
> --
> Stefan Kalkowski
> Genode Labs
>
> http://www.genode-labs.com/ · http://genode.org/
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> <mailto:Genode-main at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
>
>
>
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
--
Stefan Kalkowski
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
More information about the users
mailing list