Hey, thanks for your replies.
Short heads-up: the current mainline does no longer contain any > kernel-level synchronous IPC. All IPC is asynchronous now. You may want > to apply some changes to your C++ binding. > Thank you for pointing this out. Since I updated the used revision of HelenOS to 1711 (coming from 1530), this is what I have to cope with at the moment. It seems that I have to rewrite at least 70% of the code for the IPC framework, since I used mostly synchronous framework during the GSoC. This first of all concerns the general "lower level" access to IPC functionality. But I hope to be able to recycle most of the higher level implementations I wrote during the GSoC (e.g. the ipc manager threads for accessing the answerbox, thread utcb's for message queuing, etc.). After reading HelenOS's source code and a bit of try-and-error coding I think I found my way around the asynchronous framework now. There are already plans how the formerly coded higher level implementations can be adapted to it. However there are some questions concerning the asynchronous ipc framwork, which occurred during the last days (or things I figured out by trying and I just want to assure, that I am not assuming something completely wrong): - When sending an asynchronous message, the answer to this message is always dropping into the answerbox of the task the original message was sent from? - The callid of the answer to a previously send message can be calculated by adding 1 to the callid of the send message? (so that the answer can be assigned to the right message) - When an answer arrives, the return code of the answer is located in the field args[0] of the returned ipc_call_t struct (which is retrieved through a call to IPC_GET_RETVAL())? - When an answer arrives, the in_task_id of the ipc_call_t struct is always 0 and the in_phone_hash is only sometimes filled? (only tested with messages containing the imethod IPC_M_CONNECT_TO_ME) I don't know if I did not search the right places, but it seems to me that these issues are not documented apart from in your source code (which is by the way incredibly well read- and understandable. really nice work with that) I created a new branch [1] in my formerly used repository, so everyone interested in my curent work is able to have a look at it :-) Cheers, Tobias [1] https://github.com/kurbel/genode/tree/dipl-spartan
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
