-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Björn,
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 ipc_wait() call.
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.
Ahh, OK.
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.
Cheers
Robert
Bjoern
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers