"e" == edmundo edmundo@rano.demon.co.uk writes:
e> Dear Hackers, e> I've been studying the descriptions of IPC in the L4 Reference Manual e> (x86) and the L4 User Manual (MIPS)
Note that the User Manual uses the MIPS API in examples, but describes L4 in a mostly hardware-independent way.
e> and would be grateful if someone e> could confirm to me that I've correctly understood some points which e> are not explicitly stated in those manuals. Here's are my e> hypotheses/deductions; please tell me if I'm right or wrong!
e> (1) Both the "send message descriptor" and the "receive message e> descriptor" allow in-line data, strings and fpages to be transmitted e> in both directions. In fact, the names are confusing and they might e> better be referred to as "client message descriptor" and "server e> message descriptor" as the only differences between them relate to the e> way the other party is addressed - plus one little optimisation for e> the case where a "receive message descriptor" wants to receive just an e> fpage.
Not correct. A single IPC system call can have a send and a receive phase. The "send descriptor" describes what is to be sent, and the receive descriptor describes what can be received. For the IPC to be successful, the sender's send descriptor and the receiver's receive descriptor must be compatible.
Every successful IPC transfers some by-value data: the register part of the direct string (8 bytes on ix86, 64 bytes on R4x00). In addition, the following may be transferred, provided the send descriptor says so, and the receive descriptor allows it:
- a bigger direct string, provided that - the send descriptor points to a "message" struct specifying a non-zero number of dwords in the "send dope", and - the receive descriptor points to a "message" struct specifying a non-zero number of dwords in the "size dope", and - there is no error
- one or more indirect strings, provided that - the send descriptor points to a "message" struct specifying a non-zero number of strings in the "send dope", and - the receive descriptor points to a "message" struct specifying a non-zero number of strings in the "size dope", and - there is no error
- one or more page mappings or grants, provided that - the "m" bit is set in the send descriptor, and - the beginning of the sender's direct string (starting with the register part) contains at least one valid "send fpage", and - the receive descriptor either has the form of a valid "receive fpage", or points to a "message" struct containing a valid "receive fpage", and - there is no error
e> (2) If you want to transmit some data from thread S to thread T, one e> way of doing it is to get thread S to do a SEND operation and thread T e> to do a RECEIVE FROM operation, but you could equally well get thread e> S to do a RECEIVE FROM and thread T to do a SEND, as the "RECEIVE e> FROM" and "SEND" IPC types have nothing to do with "receive" and e> "send", really.
Incorrect, see above. A "SEND" IPC is a special case of the general IPC op, where a nil receive descriptor is specified, and thus no receive takes place. Similarly, a "RECEIVE FROM" is a special case of the general IPC op, where a nil send descriptor is specified, and thus no send takes place.
e> (3) When you do a CALL operation, specifying both a "send message e> descriptor" and a "receive message descriptor" in the same system e> call, in most cases you probably only want to send data with the e> former and only receive data with the latter.
Whether you want it or not, that's what you get at best. The send descriptor specifies the send operation, the receive descriptor specifies the receive operation of the IPC.
e> Since both descriptors have space for both directions, you can use e> the same message descriptor as both send message descriptor and e> receive message descriptor, if you want. But you don't have to.
Yes. Both, the send and receive descriptors can point to the same struct, which then describes both the send and receive part of the IPC. This is frequently used, and means that the direct string of the send gets overwritten by the receive, as get indirect strings (if any).
I'll put some of this into the user manual for further clarification.
Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 _,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F