Hi, sorry for not responding for such a long time. Thank you for all the comments. After reading them and discussing the issues with Stefan we concluded what the solutions would look like: - To keep it simple every communication will be made through kernel IPC mechanisms. Therefore every syscall will contain the specific thread-id the message is addressed to as one of the free arguments. - Since Genode is using a Messagebuffer for communicating, every communication will be made through the syscall sending complex data. - There will be one manager thread per task for incoming calls. It will dispatch those calls to thread specific call queues. The manager thread will be started as soon as the first worker thread is waiting for an incoming call (e.g. when a service is registered or a callback connection requested). - The Core task in Genode will be acting as a initial naming service. When a new task is spawned it will ask Core to connect to it's parent. Therefore Core has to keep track of the task hierarchy My current progress on those things can be found in my upcoming weekly report of last week.
Cheers Tobias 2012/6/18 Norman Feske <[email protected]> > Hello, > > thanks Tobias for the interesting report. I have only very little to add > to the comprehensive responses of Jakub and Martin. > > >> (2) - Problem 2: The first loaded task in the Genode Framework is per > >> definition the "core" task. As far is I can judge core has to do > >> nothing at all with IPC mechanisms. In the current state I do not know > >> any solution to this problem, since I have not such deep knowledge of > >> the Genode system. > > Actually, core happens to perform IPC with itself. When spawning the > init process, core uses its own services such as RAM, RM, CPU to > construct the child process. E.g. ,the innocently looking function call > in 'base/src/core/main.cc' at line 225 is an RPC call: > > env()->ram_session()->transfer_quota(init_ram_session_cap, init_quota); > > Hence, core expects the IPC framework to work at this stage. But from > what I gathered from Jakub's mail, this does not look like a fundamental > problem. > > When it comes to process creation, my intuition is to let core play the > role of the naming service. It is then up to core to let the other > processes know each other according to core's policy, in particular to > establish the communication channel of a new process to its parent. Btw, > the latter problem is already captured by the API of core's PD service > (PD = protection domain) that is used to create new processes in Genode > (see 'base/include/pd_session/pd_session.h'). After creating a PD > session, the PD client (the parent of the new process) is able to define > itself as the parent of the new child via the 'assign_parent()' > function. On most platforms, this procedure is performed by the > 'process' library ('base/src/base/process/process.cc'). On SPARTAN, you > will most certainly need to replace this implementation. > > Regards > Norman > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
