Looks like unnecessary mapping of capability
jaeyong yoo
y.jaeyong at ...9...
Mon Feb 4 00:48:42 CET 2013
Ah! Now I understand!
Because the Msg_buf could be reused, the indices in Msg_buf should be only
used for receiving new capabilities.
Thank you very much for the kind answer :)
Best regards,
Jaeyong
On Sun, Feb 3, 2013 at 10:10 PM, Stefan Kalkowski <
stefan.kalkowski at ...1...> wrote:
> Hi Jaeyong,
>
> On 2013-02-01 03:47, jaeyong yoo wrote:
> > 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'll take you at your word ;-)
>
> > 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?
> >
>
> Actually it is possible, but then we must instead allocate a new
> capability index within the "Msg_buf" object, from where the "kcap"
> argument originally comes from.
> As stated in a previous mail: the capability indices in the message
> buffer are used to receive new capabilities. If we just use these
> indices without allocating new ones, newly received capabilities would
> override the old ones.
>
> Does that answers your question?
>
> Best regards
> Stefan
>
> > Best regards,
> > Jaeyong
> >
> > On Fri, Feb 1, 2013 at 4:20 AM, Stefan Kalkowski
> > <stefan.kalkowski at ...1... [21]> 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... [1]
> >>
> >>> <mailto:stefan.kalkowski at ...1... [2]>> 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 [3]
> >> > >
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Genode-main mailing list
> >> > > Genode-main at lists.sourceforge.net [4]
> >> > <mailto:Genode-main at lists.sourceforge.net [5]>
> >>
> >>> > https://lists.sourceforge.net/lists/listinfo/genode-main
> >> [6]
> >> > >
> >> >
> >> > --
> >> > Stefan Kalkowski
> >> > Genode Labs
> >> >
> >> > http://www.genode-labs.com/ [7] · http://genode.org/ [8]
> >> >
> >> >
> >>
> >
> >
> ------------------------------------------------------------------------------
> >> > 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 [9]
> >> > _______________________________________________
> >> > Genode-main mailing list
> >> > Genode-main at lists.sourceforge.net [10]
> >> > <mailto:Genode-main at lists.sourceforge.net [11]>
> >> > https://lists.sourceforge.net/lists/listinfo/genode-main
> >> [12]
> >>
> >>>
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >
> ------------------------------------------------------------------------------
> >> > 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 [13]
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Genode-main mailing list
> >> > Genode-main at lists.sourceforge.net [14]
> >> > https://lists.sourceforge.net/lists/listinfo/genode-main [15]
> >> >
> >>
> >> --
> >> Stefan Kalkowski
> >> Genode Labs
> >>
> >> http://www.genode-labs.com/ [16] · http://genode.org/ [17]
> >>
> >>
> >
> >
> ------------------------------------------------------------------------------
> >> 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 [18]
> >> _______________________________________________
> >> Genode-main mailing list
> >> Genode-main at lists.sourceforge.net [19]
> >> https://lists.sourceforge.net/lists/listinfo/genode-main [20]
> >
> >
> >
> > Links:
> > ------
> > [1] mailto:stefan.kalkowski at ...1...
> > [2] mailto:stefan.kalkowski at ...1...
> > [3] http://p.sf.net/sfu/appdyn_d2d_jan
> > [4] mailto:Genode-main at lists.sourceforge.net
> > [5] mailto:Genode-main at lists.sourceforge.net
> > [6] https://lists.sourceforge.net/lists/listinfo/genode-main
> > [7] http://www.genode-labs.com/
> > [8] http://genode.org/
> > [9] http://p.sf.net/sfu/appdyn_d2d_jan
> > [10] mailto:Genode-main at lists.sourceforge.net
> > [11] mailto:Genode-main at lists.sourceforge.net
> > [12] https://lists.sourceforge.net/lists/listinfo/genode-main
> > [13] http://p.sf.net/sfu/appdyn_d2d_jan
> > [14] mailto:Genode-main at lists.sourceforge.net
> > [15] https://lists.sourceforge.net/lists/listinfo/genode-main
> > [16] http://www.genode-labs.com/
> > [17] http://genode.org/
> > [18] http://p.sf.net/sfu/appdyn_d2d_jan
> > [19] mailto:Genode-main at lists.sourceforge.net
> > [20] https://lists.sourceforge.net/lists/listinfo/genode-main
> > [21] mailto:stefan.kalkowski at ...1...
>
> --
> Stefan Kalkowski
> Genode Labs
>
> http://www.genode-labs.com/ · http://genode.org/
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
>
> ------------------------------------------------------------------------------
> 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/20130204/ead5e39c/attachment.html>
More information about the users
mailing list