Dynamic creation and passing of IPC channels
robert.kaiser at hs-rm.de
Thu Dec 12 17:57:09 CET 2013
-----BEGIN PGP SIGNED MESSAGE-----
Thanks for your response.
Am 12.12.2013 09:56, schrieb Björn Döbel:
> Hi Robert,
> >>> Capabilities are passed around through standard IPC. The
> >>> difference is that you don't put them into the UTCB's message
> >>> registers but instead you out a send flexpage into the UTCB
> >>> buffer registers. Note, that the receiver must be willing to
> >>> receive and therefore has to add a receive flexpage on its side
> >>> beforehand.
> >>>>> Can anyone point me to some helpful documentation or maybe
> >>>>> an example I could cannibalize to implement this
> >>>>> (preferably in C, but C++ code would surely be helpful
> >>>>> too)?
> >>> Unfortunately, there's no example that does exactly what you
> >>> want. But you might want to look at the following two:
> >>> * l4/pkg/examples/libs/l4re/streammap demonstrates delegation
> >>> of resources (memory pages in this case) from a server to a
> >>> client. Sending cap fpages is similar - you basically replace
> >>> Rcv_fpage::mem() with Rcv_fpage::obj() etc.
> >>> * l4/pkg/examples/libs/l4re/c++/clntsrv_ns is an adaptation of
> >>> l4/pkg/examples/clntsrv that passes capabilities the other way
> >>> round. The client creates an IPC gate, sends it to the server
> >>> through an L4Re namespace, and the server then obtains this
> >>> channel and binds a server-side thread to receive messages
> >>> through this channel.
> > I *sort of* got this working, however there is a problem which I
> > don't understand.
> Would you mind sharing your example code? This would make it easier to
> understand what's going on.
I hope it is OK to send mails with attachments to the mailing list? If
so, you'll find my source code attached. In file client_c.c, line 85/85,
you'll find a commented-out ipc_receive() call followed by an
In this version, the program produces following output:
Ned says: Hi World!
Ned: loading file: 'rom/chanmap.cfg'
server | Welcome to the C channel map example server!
client | Channel map C client
client | Passing response channel to server
client | Sending item: Item received: 413008:413031
server | respthread: waiting 3 secs
server | reply cap: 0x414000
server | Do_respond received
server | # of words: 2
server | # of items: 1
server | Item received: 413038:1000260
server | Sending ack to client
server | calling reply and wait
client | Awaiting response from server
server | respthread: sending message: 6 words
client | Back from receive
server | respthread: message sent
server | respthread: hang forever
client | It worked! Message received: Hello from the server
However, if I use ipc_receive() instead of ipc_wait() it hangs after
"server | respthread: sending message: 6 words".
> > [..] I also noticed that the label returned by ipc_wait() is not
> > exactly the same as the value that was bound to the IPC gate. It
> > seems that a 1 was added or ORed to the value. Is this indended
> > behaviour?
> Yes, it is. The lower two bits of the receive label contain the rights
> with which the respective capability was mapped into the sender's
> capability space.
> As an example, this is used by memory managers to determine if a page
> fault shall be served read-only or writable. If you have the
> respective dataspace capability mapped with RW rights and call
> Dataspace::map(), the dataspace server sees this and gives you a
> writable memory mapping. If you have the Dataspace cap mapped RO, this
> call will result in a read-only memory mapping.
> The whole capability-rights concept is unfortunately not well
> documented. :(
I'm afraid, I'll have to agree here ;-)
> Luckily, most of the time you won't need this feature
> at all. In this case the rule of thumb is to simply use labels that
> have the lower 2 bits set to 0 and mask those bits after receiving a
> message, which should give you the original label.
In fact that is what I did (unwittingly) by using the address of a word
variable as label.
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3754 bytes
Desc: not available
More information about the l4-hackers