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@...1... mailto:stefan.kalkowski@...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@lists.sourceforge.net <mailto:Genode-main@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@lists.sourceforge.net <mailto:Genode-main@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main