OdinOS: I'd love some design feedback

[rdos]

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.

[rdos]

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.

[Brendan]

Hi,

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.

You're right; except that "full segmentation" involves a lot more security (and therefore a lot more overhead) and that the extra security it provides (protecting an application from itself) is useless, and this makes "full segmentation" a huge net loss; and that paging has a lot of other uses (not related to security) that makes it a huge net win (far superior to "full segmentation" ever can be or ever will be).


Cheers,

Brendan

[Kevin]

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.

When I wrote the first reply, I didn't really realise that you had the difference between CPU 0 and the rest, so I guess this mostly misses the point and you should just disregard it.

[mrstobbe]

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.

Well, I'm an idiot . That's obviously not going to work. The moment I started playing with the idea I was like, "Ummm... Tyler, wth were you thinking here?!?!" At least there's the 2M option (mostly implemented today, first day I've had a chance to write code since the OP). Working on the general kernel heap at the same time. Keeping it stupid-simple for the time being with a basic linked-list-first-fit situation (I know, I know). It's nice to actually have a bit of time to work on actual code .

[mrstobbe]

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.

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).

[rdos]

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).

Not exactly. My kernel is mostly in x86 assembly (using segmentation), so it's not so useful as an example. The signal function, which can be used both from IRQs and kernel code, is a basic primitive implemented in the scheduler. The thread waiting for an signal (event) will use the syscall "WaitForSignal". The signalled state of a thread is kept in the thread control block. WaitForSignal is guaranteed to exit regardless if the thread is signalled before the call, during the call or after the call.

Load balancing is implemented in the APIC driver, and is only available if the computer has an APIC, which all modern computers have. This code will switch the destination core of IRQs to even out load.