Re: Dynamic creation and passing of IPC channels

-----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-----

_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers