Hi Tobias, thanks for the report. Please see below for some of my reactions to your questions / suggested solutions.
On 06/17/2012 05:16 PM, Tobias Börtitz wrote: > (1) Prolbem 1: HelenOS distinguishes between IPC in the same address > space and IPC between different address spaces. The Spartan kernel > follows the ideas of a microkernel architecture in a ... way and > therefore supports IPC only for communicating between different tasks > (different address spaces). Communication within the same address space > (e.g. different threads of a single task) is supposed to be implemented > and managed in the userspace. As already stated previously, it _is_ possible for a task to talk to itself via the IPC syscalls. It happens all the time when you have e.g. a FAT file system mounted on top of another FAT file system and you do a pathname lookup across that mount point. There are no alternate userspace versions for doing IPC with the same and with another task: there is just one. It was only emphasised that when a task talks to itself, it may be better for it not to use IPC at all. Once a tasks acquires a phone to itself (e.g. some other task may clone its own connection), it can send itself messages without any constraints. So the problem appears to be how a task can universally establish a connection to itself and also the task vs. thread addressing discrepancy. > (1) Problem 2: HelenOS supports only one answerbox (queues where > incoming messages are being stored) per task. All incoming communication > for the specific task is stored there. Whenever a tasks consists of > multiple threads some mechanism has to make shure an incoming call is > processed by the right thread. For the fact that Genodes expects a call > to land automatically at the addressed thread this issue has to be taken > care of. > Possible Solutions: > a) Create one thread per task which is dedicated to fetching messages > from the answerbox and forwarding the fetched messages to the addressed > thread within the address space. This would require some relatively deep > digging into the Genode code since the task creation process would have > to altered. This is actually what our async framework does, just replace threads with fibrils (i.e. userspace threads). There is one or more manager fibrils that only can wait for IPC. When a message arrives, the manager fibril finds the respective _connection_ (handled by exactly one worker fibril) and requeues the message accordingly. > (2/3) - Problem 1: When creating a new task, the Spartan kernel is > automatically connecting this task to the first loaded task. This first > created task has to be asked for further connections to other tasks. > Therefore the first loaded task must act as a nameservice. Genode on the > other hand is expecting the newly created task to be connected to it's > direct parent (which is the creator itself) and then ask the parent for > further connections. > Possible solutions: > a) A newly created task would have to ask the first loaded task to > connect it to it's parent. The first loaded task therefore would in some > way have to know where the parent is lokated to forward the request. > This leads to the next problem: Hm, in the current HelenOS, when creating a new task, the parent has, for a short period of time, an open connection to the child. Of course, this is specific to our userspace loader service, but it makes me think whether you couldn't do something similar and, at the end of the communication, have the parent invite the child to create a callback connection via (connect_to_me) to it. > (2) - Problem 2: The first loaded task in the Genode Framework is per > definitionem 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. I will work in that tomorrow when meeting with Stefan. So what is the actual problem here? > (4) - It has to be considered carefully which syscall is used for which > task, since the syscalls differ in execution speed (how much do the > actually differ?). Which one is to use for which task will clarify on > the way of portation. If this is in reference to the slow/fast variants, the difference is that the fast variants pass all IPC arguments in registers to the kernel while the slow variants pass some arguments via memcopy_from_uspace(). There is a rule of thumb: if you can do with the fast version, use the fast version, otherwise use the slow version. It is also possible the the slow version will not be able to pass all arguments (the maximum is 6 including the method number). In that case, you can send multiple messages or a combo, i.e. a data write or read or share memory. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
