> 1. In this example, server maps the capability in the client to itself?
In this example, the server receives a capability from the client. This scenario is a bit more complicated, because the server has to prepare for receiving the capability. Your setup will most likely be simpler, because you want the client to receive the cap (if I got that right). > 2. In the server code, there are two "caps rcv_cap" and "tmp". Why do we use > tmp here? > Can't we only use the rcv_cap to receive the capability? > 3. Finally, in the server, where is the capability is mapped in? tmp or > rec_cap? As hinted above, the scenario is more complex. To receive a capability, you have to put a receive item into the UTCB used for the communication _before_ the corresponding send item is inserted. Normally the server just waits for a call and then reads out the request. The example shows how to use the wait setup to actually put that receive item into the UTCB. If instead the client should receive a cap from the server, it is rather simple: - Client puts parameters for the call into the UTCB - Client puts receive item for the cap into the UTCB - Server receives the parameters - Server puts the send item into the UTCB When the call is completed, the capability will be mapped to the client. The reason for tmp is now reusability. rcv_cap is used for every call to the server, carrying a capability. Each time the server receives that, it moves the received cap into tmp and thereby frees rcv_cap for the next request. This way, setup_wait can always insert rcv_cap into the UTCB as receive item. I hope that clears things up a bit. Cheers, Markus
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
