Kernel Design Classification/Interpretation

[xDDunce]

I have just spent the all night reviewing my OS's design, and it turned out to not quite be what i wanted... so I've decided on a re-design/re-write, and just wanted to get some opinions on my current ideas.

My overall design is in the attached picture, i'm not too sure what it would be classed as, but it could be a modular kernel.

Basic principles are:

• The kernel has basic drivers, caches debug information, and will load drivers for all detected hardware.
• The drivers will run in ring 1, to provide protection to the kernel.
• User space apps use syscalls AND software interrupts to interact with the kernel and drivers, and all drivers use syscalls to register an interaction with the debug system in the kernel.
• The kernel has total power over everything, and is able to terminate anything that may have gone wrong for any reason. Any hanging apps will be forced to quit after ~15 secs of unresponsive activity.
• Drivers will be trusted apps, but activity checks will be made just as with userspace apps.

I think that's it.

I'm considering restarting from scratch, due to messy code, in-comprehensible source tree and it makes things simpler.

my idea:

[NickJohnson]

Sounds like one of those designs that some people call a microkernel and some people don't. It all depends on whether you have memory and process management in the kernel.

Also, the whole 15 seconds kill thing doesn't sound like a great idea. What are the criteria for "unresponsiveness"? How will you distinguish services/daemons? It's usually best to separate mechanism from policy - let something outside of the kernel kill unresponsive processes: something more configurable,

Edit: Also, I wouldn't restart from scratch if you have any significant amount of code complete. Build around things, make sure your internal interfaces are clean, then refactor the old stuff. It will be much faster than throwing everything away.

[Combuster]

Sounds like one of those designs that some people call a microkernel and some people don't. It all depends on whether you have memory and process management in the kernel.

Essentially, its a hybrid, x86 oriented model that breaks the moment you want to add 64-bit support.

[Brendan]

Hi,

Just a quick note - you can't use SYSRET to return to CPL=1, so you can't let CPL=1 device drivers use SYSCALL...


Cheers,

Brendan

[xDDunce]

Hi,

Just a quick note - you can't use SYSRET to return to CPL=1, so you can't let CPL=1 device drivers use SYSCALL...


Cheers,

Brendan

noted, thanks.

I guess this may take a bit more research than previously thought, but no matter. It just means an increase in chances to learn.

Thanks to everyone for your thoughts, I will work a bit more on the design before jumping in head first (That's what i did last time, and I hope I have learned from it).

Cheers,
James

[NickJohnson]

Essentially, its a hybrid, x86 oriented model that breaks the moment you want to add 64-bit support.

So what exactly about the design makes it not portable to 64 bit? Just the use of ring based protection, or the entire design?

[xDDunce]

Essentially, its a hybrid, x86 oriented model that breaks the moment you want to add 64-bit support.

So what exactly about the design makes it not portable to 64 bit? Just the use of ring based protection, or the entire design?

I would have asked the same thing, but with no plans to go 64-bit, i see no problem in that aspect of the design. Since this is just a hobby OS, i don't really see much point in supporting 64-bit operation. On the other hand, I do think it's a very good learning experience to try out different architectures, just the same as video card, sound card etc. drivers. but overall, as long as it supports the hardware setup i will be testing it on, it doesn't matter to me as much as it does to some of the other developers on this forum.

Okay, fair enough to those who wish to cover enough drivers to support most setups of the members of this forum. It means they have more experience in (what i call) "Blind" development. They don't have the specific card to test personally, so they can't iron out those small bugs as they can with their own setup. But to manage it, with as few bugs as possible, (in my eyes) is a great achievement.

It's just in my opinion, it's better to make the most of what you've got than to wish for what you haven't. **breaks off into an "if i had a nickel..." speech...**

Cheers,
James.