Hey, 2012/7/17 Stefan Kalkowski <[email protected]>
> On 16.07.2012 15:52, Martin Decky wrote: > > Hello Tobias, > > > >> Additionally I will have to cope with the question how to distinguish > >> between ipc calls which are aactual request and ipc calls which are > >> replies to a previously send call (for asynchronous send calls). > > > > Maybe I am missing something, but can you simply make use of the fact > > that the requests and replies are first-class entities in HelenOS IPC? > > Every request needs a reply, otherwise the kernel will keep the original > > request in its data structures and the total size of the list of > > unanswered requests is bounded. > > I think Tobias point was, that the thread which dispatches messages from > the answerbox has to distinguish replies and new requests from a client > to a specific thread, due to the synchronous nature of IPC framework > that is used in Genode. That means if a thread makes an ipc-call it will > wait for the answer in the first place before processing the next > request (from e.g. a client). On the other hand, if I got Tobias > finding's about Spartan's IPC mechanisms right, there is a restriction > of IPC-answers to something like 6 words? This won't be sufficient for > the general case, so a synchronous IPC-call from the higher-level Genode > abstractions needs to be mapped to an asynchronous message in the one, > and the opposite direction right? > Or is that assumption wrong, and you can also send longer replies? > 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 > > > > BTW: As the mapping between the SPARTAN and Genode IPC concepts and the > > relation between the two implementations are becoming more and more > > complex, it might be helpful if you start documenting it. A simple wiki > > page (perhaps on http://trac.helenos.org/) might do. I was thinking > > about a table or set of tables with the Genode > > concepts/classes/terms/code snippets on one side and the SPARTAN > > concepts/types/terms/code snippets which they are mapped to on the other > > side. > > > > I know that a good code is self-documenting :), but it would be bad if > > the relation between the two worlds would stay only in your head. > > Documenting it should also help us help you more effectively. > > I fully agree with Martin with respect to documenting findings you've > gained. Not only because of the benefits to other people, but also to > prevent loosing things, and prevent for chaos in your design (when it's > only in your mind). Nevertheless, it's not about stoping your progress, > some comprehensive headwords might suffice. > I definitely agree on that. This could maybe even help myself sorting my mind a bit further. 2012/7/17 Stefan Kalkowski <[email protected]> > Hi Tobias, > > Ok, some thoughts to that. First you don't need to implement the whole > thread abstraction by now. My advice was to have a per thread-object for > the Spartan platform, that contains things like synchronization objects > when dealing with the answer-box, whether it is served by a dedicated > thread, or by alternating threads (the ones which want to receive > messages anyway). Moreover, it could contain message-buffer(s) for the > thread. Having such a class would be sufficient right now to finish the > IPC framework implementation (in it's current state it is missing any > synchronization primitives). Later, when enabling the Thread abstraction > in Genode, you can use that class as 'Native_utcb' in Genode's generic > Thread class. > This did not come across this clearly when we met (or maybe I was in a bad mental shape that day) but I kind of figured this out yesterday evening, too. > > Furthermore locks (using compare&exchange) and > > mutexes (using futex related syscalls) have to be implemented to even be > > able to lock something ;) > > You don't need to implement cmpxchg, it is available in <cpu/atomic.h>. > But you're right you need a lock-primitive. My advice was to implement a > very simple (but ineffcient variant) like the one in > base-fiasco/src/lock/lock.cc with cmpxchg and sleep. Later when you've > implemented most platform abstractions, you can implement the more > efficient variant based on the generic lock implementation (hereby the > futex syscall interface will be of great help). > 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) We've already talked about that point, and I suggested that you use the > capability id, that is transfered by every ipc-call (at least on most > platforms) to the destination-side (to identify the remote-object), as > return value to identify a reply. So no extra 'callid' is needed. But I > would await Martin's arguments, in the other mail-subthread regarding > the long-reply-messages. > See my thoughts on this above :-) (which I will try to implement in the next days) > > 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. Cheers, Tobias
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
