OSDev.org

Hi Guys,

My operating system project has progressed to the point where i need to make a decision
regarding the overall design... monolithic vs micro-kernel.

I had been planning on following the micro-kernel design,
but the more i thumb through the minix book ( and source )
the more i am being put off!

So much in-fact that I'm starting to think that I MUST be misunderstanding the design.

Take for example IRQ1 - the keyboard interrupt.
You hit a key,
interrupt service routine is called.
it sends an IRQ message to the FS driver, and iretq's
when the FS driver is run by the task scheduler, it passes the message to the TTY service.
when the TTY service is run by the task scheduler, it reads the keyboard port, and sends an ACK message...
the message works its way back ( through the FS driver again )
and eventually, after god only knows how many context switches... ( perhaps some other, unrelated process got a time slice or two )
an end of interrupt is sent to the interrupt controller !?!?!

Is it really okay to have a design that could have such an eternity between an IRQ and EOI ?

Initially, when i skim read the micro-kernel design theory, I had assumed that on IRQ-1
the kernels ISR would task switch to the TTY process, which would read the port, and send an EOI to the IOAPIC via a speicial trap.

I had also assumed that functions like getchar() would partially task switch to TTY, and receive the character via a CPU register.
but no... EVERYTHING is messages, Only mini_send and mini_receive are allowed.

Have i completely misunderstood the design ?
Or perhaps mis-understood the hardware ?

Thanks
Chris.

Hi,

cds84 wrote:Take for example IRQ1 - the keyboard interrupt.
You hit a key,
interrupt service routine is called.
it sends an IRQ message to the FS driver, and iretq's
when the FS driver is run by the task scheduler, it passes the message to the TTY service.
when the TTY service is run by the task scheduler, it reads the keyboard port, and sends an ACK message...
the message works its way back ( through the FS driver again )
and eventually, after god only knows how many context switches... ( perhaps some other, unrelated process got a time slice or two )
an end of interrupt is sent to the interrupt controller !?!?!

That seems messed up to me too.

The kernel's IRQ handler should send a message directly to the keyboard driver. The keyboard driver should handle the IRQ and call an "end_of_interrupt()" kernel API function, and then (if necessary) send some sort of "keypress packet" to the TTY service (or GUI or whatever).


Cheers,

Brendan

Is it really okay to have a design that could have such an eternity between an IRQ and EOI ?

It's probably okay for a keyboard interrupt handler because it usually has a non-shared interrupt line and keys have 10's of milliseconds between them. However, for other devices it's not ideal.

Initially, when i skim read the micro-kernel design theory, I had assumed that on IRQ-1
the kernels ISR would task switch to the TTY process, which would read the port, and send an EOI to the IOAPIC via a speicial trap.

That will work well. Or your kernel can convert interrupts to messages and send them to the driver

I had also assumed that functions like getchar() would partially task switch to TTY, and receive the character via a CPU register.
but no... EVERYTHING is messages, Only mini_send and mini_receive are allowed.

I'm not sure what you mean by 'partially task switch'. If you have a pure message-passing microkernel you will need to do a full context switch from the application that calls getchar() to the server process that will perform the service. When the key is ready another context switch will be required. This means a minimum of 2 context switches to handle a keypress. If your TTY driver is in line mode and your C library getchar() calls gets() then perhaps you will only have 2 context switches per line of text entry.

IIRC the Minix FS is where file handles are stored and this I think is the reason that the FS is involved in all these transactions. I don't know why they do it that way but it is certainly not the only way. If you keep your file handles in the kernel or use other method of authorisation then applications that have managed to open a file can send messages to drivers and filesystems directly with no middle man. The drivers know that the messages can be trusted because the kernel will have authorised the message based on a previously open file descriptor.

Don't give up on microkernels just because you see an issue with one particular microkernel.

Forget Tannenbaum :/ Read up on newer kernels, or newer design theory.

gravaera wrote:Forget Tannenbaum :/ Read up on newer kernels, or newer design theory.

What other methods are there? The microkernel way is basically to notify a process about the interrupt. Are there any more?

Not necessarily. Consider perhaps the case of a system with Intel's old I2O standard (Similar principles apply to SystemZ mainframes, a far as I understand; and are also to some extent appearing on ARM SoCs), where interrupt filters could be executed on a special IO coprocessor built int the chipset; in this case, the driver might ship a number of bytecode filters which would then be compiled for the IO coprocessor.

Now, lets consider applying this to systems without an IO coprocessor. Perhaps you would implement an interpreter for this bytecode in your kernel. Therefore, you can avoid the need to dispatch to userspace on every interrupt if it doesn't need to respond (Good example: shared PCI interrupt lines). The kernel can also have its own policies: For example "This device is generating too many interrupts and is not latency sensitive (E.G. NIC), so I'm going to switch it into polling mode and batch up requests".

Then there is finally the matter of how interrupts are dispatched to userspace (in my view, they're just a funny type of futex).

And we haven't even got into the microkernel design principles:

• Extremely synchronous (e.g. L4), known to be fast
• Extremely asynchronous (e.g. my design), probably fast (?)
• Unix style (e.g. Mach, MINIX), proven horribly slow

Thanks.

I think I'm a little closer to *getting it*.

gravaera wrote:Forget Tannenbaum :/ Read up on newer kernels, or newer design theory.

I was under the impression that Minix3 was the best OS out there for learning micro-kernel design...

Do you disagree ?

Which newer kernels would you recommend I study ?

Thanks.
Chris

cds84 wrote:Thanks.

I think I'm a little closer to *getting it*.

gravaera wrote:Forget Tannenbaum :/ Read up on newer kernels, or newer design theory.

I was under the impression that Minix3 was the best OS out there for learning micro-kernel design...

Do you disagree ?

Which newer kernels would you recommend I study ?

Thanks.
Chris

I recommend that you study all of them, as many as you can. Each kernel have their advantages and flaws and you can cherry pick solutions found in existing kernels and implement them in your kernel or an modified version of it. A few that I think are a good start are: Linux, QNX, Mach, L4, Genode OS. Looking at Minix is nothing wrong either. The more you study, the more you learn.

Hi,

cds84 wrote:I was under the impression that Minix3 was the best OS out there for learning micro-kernel design...

Do you disagree ?

Which newer kernels would you recommend I study ?

In general, the only thing you need to know about micro-kernel design is "the micro-kernel should contain the minimum necessary". The idea is that functionality that would have been in a monolithic kernel is shifted out of the kernel (e.g. into user-space) where it's easier to detect (and possibly tolerate) failures, easier to prevent bugs in one piece from trashing other pieces, and easier to have competing implementations. One of the things that is important to understand here is that "minimum necessary" is deliberately ambiguous and depends on design goals. For example, if performance is one of the most important design goals, then it may be necessary (for performance) for something like physical and virtual memory management to be implemented in the micro-kernel; even though these things aren't necessary in a micro-kernel if performance is less important than other design goals.

Once you understand the "micro-kernel should contain the minimum necessary (for any arbitrary definition of "necessary")" part, everything else is reasonably obvious. For example, with lots of pieces in user space it's obvious that they'll need a good way of communicating with each other, and obvious that they'll need to communicate often; and therefore it's obvious that you'll need some sort of IPC (typically messaging) and the design of the IPC is going to be very important. It's also obvious that (with lots of pieces in user space) scheduling (determining which of those piece/s get CPU time when) is also going to be very important. Another reasonably obvious thing is that with device drivers running in user space (e.g. as processes), you'll probably want a way to allow specific processes to access specific IO ports and "memory mapped IO" areas.

With this in mind, I'd recommend studying all the various forms of IPC (especially all the different permutations of "messaging"), and all the different ways of doing scheduling. Studying any specific micro-kernel (or many different micro-kernels) won't hurt, but it's probably a less efficient use of your time.


Cheers,

Brendan

Too add to Brendan's post

For me, a micro-kernel is all about objects. Its about understanding and recording the boundary's of components.

Where the components are run are really a side effect of having this information. What we really want is all components with memory protection etc, but its restrictions to architecture that mean we have to run some components in kernel space, and any other component running without this feature will be due to optimisation (make it run faster).

Think of Interrupts as an optimisation. They do not belong in applications or objects but in the IPC that connects them.

Mike Brown