Looks like unnecessary mapping of capability
jaeyong yoo
y.jaeyong at ...9...
Fri Feb 1 03:47:30 CET 2013
Thanks a lot. Stefan.
I think it is a very nice article for understanding Fiasco.OC/Genode IPC
and capability!
Also, reading the code, "base-foc/include/base/ipc.h," is much easier and
clearer after your kind explanation.
I would like to ask the initial question once again (I'm strongly feeling
that I have to buy you beer :) If we could meet in person, I'm gonna!).
I think it is the part that you mentioned "reality is even more complex."
In the function, Capability_map::insert_map(int id, addr_t kcap), there is
a part that allocating a new capability index:
141 /* if we own the capability already check whether it's the same
*/
142 if (i) {
143 l4_msgtag_t tag = l4_task_cap_equal(L4_BASE_TASK_CAP,
i->kcap(), kcap) ;
144 if (!l4_msgtag_label(tag)) {
145 /*
146 * they aren't equal, possibly an already
revoked cap,
147 * otherwise it's a fake capability and we
return an invalid o ne
148 */
149 tag = l4_task_cap_valid(L4_BASE_TASK_CAP,
i->kcap());
150 if (l4_msgtag_label(tag))
151 return 0;
152 else
153 /* it's invalid so remove it from the
tree */
154 _tree.remove(i);
155 } else
156 /* they are equal so just return the one in the
map */
157 return i;
158 }
159
160 /* the capability doesn't exists in the map so allocate a new
one */
161 i = cap_idx_alloc()->alloc_range(1);
It allocates a new capability index, if the already existing capability is
invalid (see line # 153).
What I'm wondering is the following:
Since the 'kcap' (parameter to insert_map func.) which is valid capability
index received from the IPC (and originally allocated in Msgbuf_base
creator), would it be possible to use the kcap rather than allocating the
new one?
Best regards,
Jaeyong
On Fri, Feb 1, 2013 at 4:20 AM, Stefan Kalkowski <
stefan.kalkowski at ...1...> wrote:
> 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/
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20130201/90d2a045/attachment.html>
More information about the users
mailing list