OSDev.org

mrstobbe wrote:Similar concept, some differences (one core reserved for tasks only), but still similar. I like the idea of IRQ balancing like that, additional overhead, but as you pointed out, rather minimal. Also, because the balanced thread is likely to be a small and consistent bit of code with very consistent behavior I would imagine it's impact of CPU state would be minimal as well. Worth exploring.

I'm starting to think that I can simplify things quite a bit by switching to a monolithic kernel design... keep the concept the same (minimal hardware support, CPU0's job is the same, etc), but it would help take some of the guesswork in who notifies who of what and why out of the equation. Probably a better starting place anyway so I can quickly start experimenting to see if the basic idea even works and learn some lessons from it. The downside is the lack of recovery potential if a driver misbehaves, but I can refactor to a microkernel as needed later.

Brendan wrote: Micro-kernel sacrifices some performance for security/stability. Monolithic sacrifices some security/stability for performance.

rdos wrote:

Brendan wrote: Micro-kernel sacrifices some performance for security/stability. Monolithic sacrifices some security/stability for performance.

Not necessarily true. What the micro-kernel actually does is that it fixes problems in the flat memory model with packed code and data structures. The fix is very costly (address space switches and TLB invalidations). Another fix for the problem of the flat memory model with packed code and data is segmentation, which preserves locality of code and data structures (at the cost of segment register loads). A third solution is to spread data randomly all other the address space, thus destroying locality but providing better security/stability.

Of course, there is no solution that doesn't cost anything. The cost depends on how well the mechanism used is implemented in hardware.

mrstobbe wrote:Super sorry Kevin, must have missed this post the other day, replying now...

It's semantics again... how would you define this design? "Micro-kernel/multi-tasking on one CPU, but the rest not"? "MkMtoocBtrn"? I should trademark that now . Fact of the matter is the kernel is microkernel design, but it's mono-process (application or whatever you want to call it) in a system-wide sense. Pure semantics though. It's not set in stone what you call it. I think I'll call it microkernel-mononormalizing-polytasking from now on.

You're wrong about the difference though, with no context switching for all but one CPU, I'd say that's significantly different than the "normal" OS.

mrstobbe wrote:I was thinking of playing with seeing if there was a way to use 32/36-bit addressing in long-mode (haven't tried it, but it was an idea I had the other day). I mean, when you enter long mode with 36-bit addressing, it uses that page setup until you tell it otherwise, so I was thinking there might be a way to take advantage of that. Processes that used this though would have to be mcmodel=small, which might be perfectly fine for less-memory hungry tasks. No idea if this is doable or reasonable even if it is, just a thought.

rdos wrote:

mrstobbe wrote:Similar concept, some differences (one core reserved for tasks only), but still similar. I like the idea of IRQ balancing like that, additional overhead, but as you pointed out, rather minimal. Also, because the balanced thread is likely to be a small and consistent bit of code with very consistent behavior I would imagine it's impact of CPU state would be minimal as well. Worth exploring.

I'm starting to think that I can simplify things quite a bit by switching to a monolithic kernel design... keep the concept the same (minimal hardware support, CPU0's job is the same, etc), but it would help take some of the guesswork in who notifies who of what and why out of the equation. Probably a better starting place anyway so I can quickly start experimenting to see if the basic idea even works and learn some lessons from it. The downside is the lack of recovery potential if a driver misbehaves, but I can refactor to a microkernel as needed later.

I use load balancing and ultra-small IRQs instead of the typical lower-higher half interrupt-handling in typical monolithic OSes like Linux and Windows. For instance, the network driver notification IRQ simply clears the pending IRQs bits, and then signals a server thread to do all the rest. That means the complete TCP/IP stack, including incoming messages from the network, are handled in a server thread, not in an IRQ. That's kind of a microkernel concept, except the server part typically doesn't switch address space or processor ring, rather typically only will do a schedule within the same process. All the system threads started in kernel space run in the system process, which means that if another system thread (or the null thread) is interrupted, no address space switch is performed.

mrstobbe wrote: That's pretty much exactly what I was envisioning in my head when you first mentioned the idea ("small and consistent bits of code"). Do you have some source that I could check out to see your implementation (not to snag it or anything, I just want to check out the implementation)? Me switching to a monolithic kernel for the time being doesn't undermine this concept. It just simplifies the whole userspace<->kernel<->driver<->kernel<->userspace interaction (you know, KISS will get you farther faster and you can always come back).