Hi Tobias, On 11/07/2012 04:14 PM, Tobias Börtitz wrote: > as the title already suggests, I am returning to my project from this > years Google Summer of Code for my Diploma thesis.
Thanks for letting us know! > 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. 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. > 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 (besides the two > papers of Martin which are referenced in the Documentation section [1]). Hm, I think it would be a mistake to try to retrospectively find some big guiding design idea behind the early stages (around 2004/2005) of the SPARTAN kernel development. At that time, we didn't even know much about the other microkernels and everyone at the University back then seems to have been thinking that microkernels were dead anyway. Also note that it took the SPARTAN kernel about three/four years before there was any userspace code in it (2001 - 2004/2005). It was able to run on SMP machines and two arches (ia32 and mips32) before the first uspace instruction was executed. Naturally, the foundations for the in-kernel memory management came into existence in this period. I remember that when our IPC was designed, we had just learned about the L4 existence (MINIX 3 was still in stealth mode). Neither that discovery influenced the design though, as anyone can easily verify. If anything, I'd say we wanted HelenOS to be unique (as in not cloning any existing OS or its API), portable and use some advanced algorithms, such as the slab allocator with magazines, B+trees etc. To a large extent, it was a pretty substantial programming exercise. We used our common sense, stuff that we had then learned in university lectures, and our imagination. > Especially papers regarding your decisions towards the ipc design and > why memory management, some drivers and a framebuffer are integrated > into the kernel would be great. As for the IPC design, I think its author, Ondra Palkovsky, wanted it to be based on some nice metaphor. Back then, he was also a sort of software engineer avant-gardist, always fond of things like lambda functions, nested functions, asynchronous IPC without callbacks, thread local storage, you name it...) Interestingly, it is possible to map HelenOS IPC entities to Mach IPC entities. So that a Mach send right corresponds to HelenOS phone, Mach task port corresponds to HelenOS answerbox. In Mach, you can send the send right to someone else. This is roughly equivalent to forwarding IPC connections in HelenOS. I realised this much later when I finally read the relevant microkernel papers and literature. As Martin already replied regarding the in-kernel drivers, their purpose is only to allow the kernel to print something on its own and accept commands for the kconsole. This is entirely debugging and not essential stuff. In fact, I've been planning to get rid of most of these. Of course, the real drivers live in userspace. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
