Hello Tobias,
as the title already suggests, I am returning to my project from this years Google Summer of Code for my Diploma thesis. The final goal for the thesis is yet to be set, but I intend to revisit my implementation from the IPC framework onwards, backing the implementation with more theoretical knowledge.
That's great news! I am looking forward to both the goals you are going to set and the resulting thesis.
Since I am currently reading literature for gaining the necessary theoretical knowledge, I wanted to ask if you could provide me with some papers which inspired the design of the SPARTAN kernel
Well, maybe the others will come up with some specific references, but according to my own recollection the design of the HelenOS IPC (and the lowest tier -- the SPARTAN kernel IPC) is our original creation. It is not explicitly based on any theoretical paper nor modelled according to any pre-existing implementation.
Having said that, the HelenOS IPC certainly takes general inspiration from many message passing middlewares and asynchronous microkernel IPC mechanisms. And of course, you should be able to identify many traditional key concepts of message passing in our IPC. But the way it is all put together is specific to HelenOS.
Especially papers regarding your decisions towards the ipc design and why memory management, some drivers
Speaking about these features: They are all in the kernel because it is almost inevitable to have them in the kernel. At least it would be extremely and unjustifiably complex to implement them in user space and they would most probably still require some kernel support for any reasonable operation.
For example, it would be extremely cumbersome (if at all possible) to manage virtual-to-physical memory mapping without virtual and physical memory management mechanisms in the kernel. The same goes to preemptive scheduling and timer interrupt handling. Essentially, having these basic mechanisms in the kernel solves the chicken-and-egg problem.
One of the basic design principles of HelenOS is called "the split of mechanism and policy". It is beneficial to implement some low-level mechanisms in the kernel, however more complex policies that can be built on top of the low-level mechanisms should be implemented in user space. That is why the kernel implements only the lowest tier of HelenOS IPC, while there are at least two more abstract and more complex IPC tiers implemented in user space.
and a framebuffer are integrated into the kernel would be great.
The kernel framebuffer (and serial drivers, keyboard drivers, etc.) are implemented in the kernel _only_ as development and debugging aids. They are not essential for the operation of the system, the user space is designed to have their own and completely separate drivers. (*)
Basically the only kernel drivers that are actually essential for the operation of the system are the timer and primary interrupt controller.
(*) Some of the kernel drivers actually do pass some essential information to the user space drivers. But this is always only due to historical reasons and it needs to be reimplemented cleanly sooner or later.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
