Hey,
this is my summary of week 4 into the coding period of the Google Summer of
Code.
The last week I first of started to make the IPC related syscall available
in my repository and have then been working my way step by step into the
knowledge how to use them. Therefore I created the ipc_pingpong test where
two tasks (ping & ping) are registering themselves to a nameserver
(nameserv), which is keeping track of all connections. The code doing all
this is not all that pretty, but for the fact that is only for the purpose
of getting to know how to use the syscalls it is doing it's job. I intend
to replace all that as soon as there is a usable interface for Genode.
While creating the test mentioned above, I have been reading documentation
and source code of HelenOS as well as Genode for the purpose of getting an
idea how both systems work (concerning ipc mechanisms), on what ideas they
are based and what they are expecting to be done in order to do IPC.
Following up I will try to list differences between both systems, point out
the problems which arise from that and afterwards try to introduce some
some ideas and approaches of mine for solving those problems.
Differences:
Criteria | Helenos provides | Genode
expects
-------------------------------------------------------------------------------------------------------------
kernel | between tasks only | between threads,
no
supported ipc | (separate address spaces) | knowledge of tasks
(1) | - identified by their id | needed
-------------------------------------------------------------------------------------------------------------
standard ipc | to initial namservice | to the parent of
the
connection when | (defined to be the first | created object
new task is | task loaded by the kernel) |
created (2) | |
-------------------------------------------------------------------------------------------------------------
service routing | by special nameservice | by parent of every task
(3) | (standard = first loaded | / thread
| task) |
-------------------------------------------------------------------------------------------------------------
interface for | many possibilities to send | one interface to send
sending | a message - with and | messages (cin /
cout
messages | without messagebuffer / | like writing into a
(4) | sychronous, asynchrounus | buffer + simple
send()
| fast (few arguments) / | function
| slow (more arguments) |
>From those differences arise several problems. I will try to describe the
problems in descending order of the differences they arise from and
introduce some ideas and approaches how to solve them.
(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.
Genode on the other side expects the same interface for communicating
between threads inside the same address space and threads in different
address spaces.
Possible solutions:
a) A userspace implementation which is transparent for the threads,
distinguishing whether communication is in the same task or to another task
and acting accordingly. Within the same address space messages would be
passed via shared memory or something alike. For Communication between
different address spaces ipc mechanisms provided by the kernel would be
used.
b) Using syscalls for every communication, even for communication between
threads in the same address space. Therefore a task would have to be able
to connect to itself and pass the specific message to the right thread.
With this we are facing the next problem:
(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.
b) Every thread waiting for a call would look up the answerbox (while
holding a lock) itself. On an incoming call the thread would have to check
whether the call is for it or not. In case the call is not for the thread,
the call would have to be stored in an extra, task specific call-queue. So
when looking for an incoming call, a thread would first have to look up the
call queue of the task. When there is no message for this thread in this
queue, it would look into the answerbox. This scenario would require two
locks: one for the anserbox and one for the call queue so that it would not
end in an endless busy waiting scenario.
(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:
(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.
(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.
These are my thoughts so far. It is quite possible I forgot something, did
not describe something in needed details or even got something wrong.
So when stumbling on any issue, please feel free to add knowledge, ask
questions and correct me.
Regards
Tobias
P.S.: I will meet with Stefan tomorrow. We will discuss all of these issues
and hopefully come up with some more solutions and ideas how to solve the
problems. Needless to say, I will report those as soon as possible.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
