-----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 > [email protected] > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKp6t0ACgkQiRNSGeNtqcloAAD/TnBnYRYPg47mUDKCteoIhEIy fViu804OK/f7TPIEYZEA/ReIBVI2tCW0mnKoE6Uu64K6o5jvR+qwiGWy9eHtpE3l =KOh7 -----END PGP SIGNATURE-----
chanmap_c.tgz
Description: GNU Unix tar archive
_______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
