OSDev.org

Hi all

i spent some time recently on thinking about a reasonable kernel design (also reading some of the design related posts here), and came up with the following (Image attached...).

Just as a quick additional explanation:

1) Photon is more or less a "stage 3 bootloader". after grub loads it, it sets up the long more environment, and calls tachyon (after loading the right things from the TSI (Tachyon System Image). The TSI is more or less equal to a virtual hard disk with differencing disks, which makes it possible to (for example) store user changes to the system in a seperate differencing disk and (on demand, if the kernel doesn't boot anymore) simply load without those changes, effectively resulting in an unmodified base system. the TSI should contain the kernel itself and all (or many of) the basic drivers.

"Priviledged" means really "Ring 0", "Semipriviledged" is "Ring 1" and "Unpriviledged" is "Ring 3".

All of this is far from complete/finished, so i know there are many things (especially devices of course) missing. Basically i want to create a "basic" design, and not a complete diagram of all supported devices, so the ones that *are* in the graph are exemplary only. Also there may not be all the relationships correct ATM (for example i just saw, that the DataServer will most probably depend on the Device Management to get informed if a new disk becomes available, etc., etc.).

Any big ideas/comments/critics/scolding or simply questions on this? Any words appreciated!

Thanks for taking the Time to review, i know it grew a little big in the last hours

It sure is an interesting design, but looks extremely difficult to code. I hope you know the time and effort this will take to do, as well as the required knowledge and tools. I look forward to seeing the results, as it appears to be a promising design and idea for a 64-bit kernel/OS!

OT: Do you mind telling me how you made the little "folders" and such in that image? Thanks

Good luck,
Troy

So... what's the design? The fact that the EHCI controller is related to the EHCI driver isn't a design decision. Why use ring 1 at all? I can find absolutely no use for it (also, it makes your design less portable to other architectures). You "minikernel" is just a another boring monolithic.

<sarcasm> How long did you spend on the nice little picture there? </sarcasm>

Although I wouldn't agree that it's "just another boring monolithic" - I'd say it's a hybrid: a microkernel for I/O drivers but a monolithic for process management - he's right about using ring 1. In fact, for x86_64, there are only rings 0 and 3, so you can't even write it that way for the architecture you're targeting.

Troy Martin wrote: OT: Do you mind telling me how you made the little "folders" and such in that image? Thanks

i used "ArgoUML" to create the UML drawing, any other UML modelling tool should be capable of doing it though

Love4Boobies wrote:So... what's the design? The fact that the EHCI controller is related to the EHCI driver isn't a design decision.

So you didn't read what i wrote carefully enough. as i stated above, all devices in the graph are just exemplary to see where they'll end up in the big picture.

Love4Boobies wrote:Why use ring 1 at all? I can find absolutely no use for it (also, it makes your design less portable to other architectures).

since all but the "Tachyon" Package itself (in the priviledged services) are seperate processes (Only the Tachyon Package is the "real" kernel"), it really doesn't matter which ring those services run on in the end. i chose ring 1 to create a distinction from the priviledged and unpriviledged services, but they may run as well in ring 3 in the end - they're just "servers" as in a micro kernel design.

Love4Boobies wrote:You "minikernel" is just a another boring monolithic.

although i tried to not calssify my design in the first place until i found out about some basic design, i guess you could call it a nano kernel as well. only messaging is contained in the nano kernel (the Tachyon Package in the graph), and some boot services, just required to bootstrap memory and process management. There are defined protocolls from transfering control from (for example) the boot service memory manager to the core service memory manager (which runs in a seperate process (in whatever ring)).

Seems some things where unclear . sorry about that.

Love4Boobies wrote:<sarcasm> How long did you spend on the nice little picture there? </sarcasm>

about one and a half hours. i don't understand sarcasm ( ).

NickJohnson wrote:Although I wouldn't agree that it's "just another boring monolithic" - I'd say it's a hybrid: a microkernel for I/O drivers but a monolithic for process management - he's right about using ring 1. In fact, for x86_64, there are only rings 0 and 3, so you can't even write it that way for the architecture you're targeting.

Hey, thats the type of comments i was looking for. I wrote a small 32 bit kernel until now only, so i didn't know about the x86_64 restriction. that helped as i said already, the ring doesn't really matter - thats also the reason i didn't name it "Ring 0" in the picture, but "Priviledged Services". However protection is enforced (Hardware or Software), the important part is that there *is* protection (whatever it will look like in the end).

The plan is to switch off the kernel contained memory and process management after bootstrap succeeded - so i don't know wether this counts as "kernel conatined" or just as helpers during boot. Of course if no other memory manager appears, the boot service may continue working as well.

I hope that lifted the haze a little

Cheers, Markus

NickJohnson wrote:Although I wouldn't agree that it's "just another boring monolithic" - I'd say it's a hybrid:

Sorry, I'm one of the people who don't believe in hybrid kernels They are monolithic to me.

mduft wrote:although i tried to not calssify my design in the first place until i found out about some basic design, i guess you could call it a nano kernel as well.

Nanokernels are extreme versions of microkernels. I can see both your process and memory managers are part of the kernel.

Love4Boobies wrote:Nanokernels are extreme versions of microkernels. I can see both your process and memory managers are part of the kernel.

Yeah i know, thats why the kernel contained memory and process management is *only for booting*. i said that before, and i also said that this may be counted as cheating, but i'm unsure. Comments like yours don't help me very much since you answer questions i never posed.

however appart from discussing what type of kernel this would be (it really really really doesn't matter to me. if it's a big bunch of 10.000 source files all compiled into one big fat binary it would be ok with me - but that doesn't do what i want to do, so i need a non-monolithic kernel anyway), i'd like to hear what you all think about ideas like booting off of a virtual harddisk (with possibly differencing images)...? (i would of course need grub to load the TSIs from disc).

Also i'm kind of stuck on how to implement messaging. it feels rather slow to copy around buffers all the time, but just mapping pages around from/to different processes feels somewhat problematic too... how do you guys do it? My first thought is to implement it (as a first shot) by copying the message from userspace to the kernel. the kernel has mapped the message queues of all processes, and each process has mapped it's own queue. so the kernel can enqueue a message and the userspace process will immediately see it (the next time it gets scheduled of course).

So, Love4Boobies, if you (this time) read the whole post, it's your chance to shine, and give me some usefull information... Even though your comments wheren't actually very helpfull, i still want to thank you for taking the time and (obviously only partially) read through this. OTOH maybe it was me not beeing clear enough... please tell me if it's like that.

Cheers, Markus

If you only allowed synchronous messaging then it would be a single copy from sender to receiver. If you allow asynchronous messaging then you could try a shared memory ring buffer, that might allow you to get rid of the copy. Page mapping or shared memory should be used for anything that's bigger than a page. You could allow big synchronous messaging and small asynchronous messages so that the copy would be relatively cheap. Just some random ideas.