Hi Tobias, sorry for my late response, I was quite busy today.
On 17.07.2012 17:49, Tobias Börtitz wrote: > Since nearly every call (request) in Genode has more payload than 5 > words (there is place for 1 method + 5 args in every call) which can be > transported via a "normal" ipc call I use a synchronous call using the > IPC_M_DATA_WRITE method (copying memory from the caller to the callee). > This call of course has to be answered by the callee, but it can only be > answered by accepting or denying the incomming data. A reply in Genode > contains a certain amount of payload (like the request itself), which > can't be stored in the answer of the incomming call. So a new call from > the former callee to the caller is beeing made (using a synchronous call > using the IPC_M_DATA_WRITE method), which currently looks to the caller > similar to new incomming call and is not able to determine whether this > is a completely new call, or a reply to the former call. This procedure > also necessitates, that the callee must have a (temporary) callback > phone to the caller. > So after thinking about this today I am planning to add > the IPC_M_DATA_READ (copying memory form the callee to the caller) call, > and implementing a kind of protocoll for sending a request and, on > success of sending this, waiting for the answer for this call. The > communication would look like this: > 1) caller opens a phone to the callee > 2) caller sends request to the callee using the IPC_M_DATA_WRITE method > 3) on success of sending the caller calls the callee again using > the IPC_M_DATA_READ method > 4) the callee stores the reply in the memory to be copied to the caller > 5) on success the the caller has gotten the reply for his request > Benefits of this would be, that > 1) the caller would not have to determine between new incomming calls > and answers to former made requests and > 2) the callee would not need a callback phone to the caller which > reduces complexity I think this will work, although it forces the callee to wait for the caller reading the response, which makes services in general vulnerable to denial-of-service attacks. Or if you encounter that problem by using timeouts you get into trouble dimensioning the right timeout value. Nevertheless, at this point I would prefer a working solution in the first place. Nevertheless, what about sending a reply phone-handle in every ipc-call the same way as all other capabilities will be transfered (meaning cloning a phone-handle). Thereby, the callee can answer the same way like the caller had send its request, and doesn't rely on the caller's preparedness, or is that wrong? > I think I implemented a mixture of this yesterday. I have been using > the cmpxchg from <cpu/atomic.h> and when the lock could not be aquired > use the futex syscalls to wait for the lock to be unlocked (while > counting the number f waiting threads). When unlocking, one the waiting > threads (if any) is woken up and will eventually aquire the lock. > (i did not yet push this to the repository) It would be fine, if you can push that stuff more regulary in general. The last commit to the branch is 7 days old. It helps me to identify issues you've already tackled too. > I see a point in that there is no combined IPC_M_DATA_READ_WRITE > method (there are the separate IPC_M_DATA_WRITE and IPC_M_DATA_READ > methods which transfer data by memory copying in one direction > only). Such a combined method can be easily implemented if it is > worth it and if that would help Tobias. On the other hand, > everything that can be achieved by memory copying can be in > principle also achieved by memory sharing. > > > Well this would make handling sending a request and receiving a reply > even more easy, since the callee would not have to wait for the new call > from the caller, requesting the reply. Additionally this would reduce > the amount of syscalls used to perform a communication. Of course, this would prevent the DoS-attack I addressed at the beginning. Regards Stefan -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
