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? > > 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. Regards Stefan > > > M.D. > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel -- 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
