PIT in a Micro Kernel

[elaverick]

Presumably in a Micro-Kernel the PIT should remain as a user space driver, I also assume that with Round robin scheduling for multi-threading you're going to need access to the PIT. Isn't this going to make operations involving Kernel threads appaulingly slow as they have to jump out and then back each time?

I like the idea of a Micro-Kernel but with this in mind I'm very tempted to bring the PIT back into the Kernel, although this would seem to be against the general design philosophy.

Also this would seem to suggest that I need to load a file system driver before I load the PIT, which seems a bit backwards to me.

Anyone have any thoughts on the matter?

[Pyr0Mathic]

hi,

dont know much about micro kernells, but this is what i use.
Set the PIT so that it generate an irq every 1/18th of a second and then i always switch from 1 task to another on that irq.

Regards
PyroMathic

[Combuster]

Personally, since I consider the PIT timer essential for OS operation, I have put the code for that in the kernel, microkernel or not.

However, the PIT isnt the only timing device - IIRC you have the watchdog, the realtime clock, and on rare machines another cmos timer. The kernel could use one of those instead, and so does the userspace app.

Alternatively, could build your OS to be (soft) realtime and have the timer-sensitive app be scheduled X times a second.

[elaverick]

Ok, I think after having a bit of a hunt around I'm going to put the PIT in the Kernel directly. Since this and one or two other components really benefit from being in the Kernel I've decided I'm no longer really making a Micro-Kernel as such. Instead I think I'm going to refer to it as a Mini-Kernel, it's certainly not Monolithic but I can't justifiably call it a Micro-Kernel any more either.

I've decided I will allow drivers in the Kernel provided they meet all of the following conditions:

1. Can reasonably expected not to crash on their own.
2. Are in some way essential to the running of INTERNAL kernel services.
3. Would adversely affect the speed of execution of the Kernel if they were run externally.
4. Interface with hardware which contains no moving parts.

The fourth point is kinda repeating the first one I suppose but I think it bears restating

[Combuster]

Shifting the topic a little, but worth the note: I don't think putting the PIT code into the kernel will break microkernel design at all, since unless you do an cooperative multitasking or monotasking os the kernel NEEDS a timer device.

My kernel is designed to be pretty minimal as well, which means that my kernel ends about where the true platform-specific parts end. This means that my kernel does memory and resource management, as well as threading and scheduling. It means that the kernel controls the CPU, PIC, PIT, APIC and IOAPIC - only that whats needed to maintain the kernel itself. (I have all other drivers run in userspace like the regular microkernel)

( Further reading: You might want to browse this thread which goes about what kernel interfaces should have. http://www.mega-tokyo.com/forum/index.php?board=1;action=display;threadid=9711 )

[elaverick]

I suppose what it really gets down to is how you define things such as Micro-Kernel or Nano-Kernel. You could still have the PIT outside the Kernel allow multitasking by loading it in as a module from GRUB.
For me this would suggest a true Micro-Kernel approach as it is an external (to the CPU) interrupt generating device and set in an external driver.
While the PIT would be external to a Micro Kernel, the scheduler (which would of course rely upon the PIT) however would be internal.

For me a Nano Kernel would have both the PIT and scheduler external to the Kernel.

These are of course just my way of thinking of those terms, hence the reason for my defining an additional term for the specific hybrid kernel approach I am taking of Mini-Kernel.

It's like the old computing joke really isn't it... What's the one thing better than a single unified standard? LOTS of unified standards...

[Pype.Clicker]

well, if you're wondering about whether the PIT should or should not be in your xxxo-kernel, i suggest you sit down and take the time to think "what is xxxo-kernel, anyway?"

Typically, we define micro-kernel as "only offering very little amount of abstractions, but abstractions on which we could build anything else". I'd be tempted to say that the reasons which i'd consider timer IRQ handling (and scheduling) part of the microkernel would be:

1. threads are a useless abstraction unless you can schedule/dispatch them to a CPU, and you need some timer IRQ for that
2. if the scheduler is in a server and if that server (for any reason) stops working, how could we detect/recover the system ?

If you're unhappy with seeing PIT frequency setting or picking between PIT/APIC for internal clock, just leave that to the "bootstrapper" program ... my biggest mistake with Clicker was to want it both "micro" and self-booting, while many things you do in the bootstrap are clearly out of what the microkernel should worry about.

[Colonel Kernel]

Ok, I think after having a bit of a hunt around I'm going to put the PIT in the Kernel directly. Since this and one or two other components really benefit from being in the Kernel I've decided I'm no longer really making a Micro-Kernel as such. Instead I think I'm going to refer to it as a Mini-Kernel, it's certainly not Monolithic but I can't justifiably call it a Micro-Kernel any more either.

Sure you can. L4, QNX, and Mach all manage the PIT and the PIC/APIC in the kernel, because it's the practical thing to do. OS design is not dogma...

[B.E]

In theroy a micro kernel is the best type of kernel, because it has the best program protection (there are other reasons, just can't think of them at the moment). But in practice because every thing in the system has to communicate though message passing (progam A want to talk to program B), and things like putting the PIT in user mode make a micro kernel design is inherently slow.

This the reason linux and windows use a different design.

[Brendan]

Hi,

In theroy a micro kernel is the best type of kernel, because it has the best program protection (there are other reasons, just can't think of them at the moment). But in practice because every thing in the system has to communicate though message passing (progam A want to talk to program B), and things like putting the PIT in user mode make a micro kernel design is inherently slow.

IMHO there's a compromise - simplicity & speed vs. protection & modularity.

Shifting anything to user-space can reduce the speed of the OS (because you end up with more context switches and IPC overhead) while improving protection and modularity (as anything in user-space is isloated from everything else and could theoretically be stopped, replaced, restarted, etc).

In the most extreme case, the "kernel" could include interrupt handling stubs, a low level "switch to task X" routine, some IPC code and some routines to manipulate page directories and page tables, with everything else in user-space (most of the scheduler, the physical memory manager, most of the linear memory manager, etc).

Some things should never be in the kernel because the advantages of putting them in user-space are far greater than any disadvantages. Examples include applications, "daemons", GUIs, CLIs, etc. For some things the advantages are more than the disadvantages (keyboard & mouse, floppy, sound, printer).

Some things are "borderline", where the advantages and disadvantages might cancel each other out (depending on the goals of the OS). This includes hard disk controllers (IDE & SCSI), video, USB controllers and some network cards.

Then there's things where the disadvantages are probably more than the advantages. In this category I'd include high speed network cards, the scheduler (and it's timer/s), the linear memory manager, the physical memory manager, etc.

So the question is, for each "thing", what are the advantages and disadvantages of shifting it to user-space, and is it worth it?

In the past the answer was often "no", because there were fewer devices and CPUs were slower (for e.g. an average of 5000000 cycles of overhead each second works out to 5% of CPU time on a 100 MHz CPU and 0.25% of CPU time on a 2 GHz CPU). For the number of devices, back when 80386 was "new" there was much fewer devices to worry about - it wouldn't have been hard to make sure all device drivers were reliable. Now there's thousands of devices and it'd be impossible to guarantee that each device driver always does what it should. As things progress, the advantages of shifting things to user-space become more important than the disadvantages...

Given that Vista has taken Microsoft over 5 years to make, it would be optimistic to say any of us will be able to produce a useful OS in less than 10 years. In 10 years time, for each "thing", what will be the advantages and disadvantages of shifting it to user-space, and will it be worth it?

This the reason linux and windows use a different design.

Linux "borrows" concepts from micro-kernels. For Microsoft, in Vista most USB devices and half the sound & video is shifted to user space. I saw a video about their "User-mode Device Framework" - the guy responsible for designing this framework mentioned a "dancing Homer Simpson" that plugs into a USB port, and how insane it is that people need to mess around in kernel-mode to make Homer dance...


Cheers,

Brendan

[elaverick]

All interesting points, it sounds as though the general concensus is that design theories are all well and good but you shouldn't slaveishly follow any one to the detriment of your kernel. I guess this means that all kernels (unless designed specifically for a proof of concept or something similar) will have some aspect of hybridisation.