Micro Kernel

[theubu]

Hey...

Any micro kernel developers out there?

If so what are you guys doing to cut back on context switching overhead with your MPI? Using syscall/sysenter?

[smiddy]

I am curious about this new-fangled-phenomonom too.

My main concern is understanding how hardware drivers are used and developed for a micro kernel environment, considering a few constructs I've seen do not have a "Hardware Manager" as part of their basic setup. This is baffling me.

[theubu]

The way I kind of see it is.... The kernel itself must have a resource manager that that driver speaks with atleast to alloc IRQ, I/O and DMA info with and communicates with it... I don't think the kernel would allow a driver task to be priveleged high enough to actually directly interface with hardware but I'm not sure...

[gaf]

If so what are you guys doing to cut back on context switching overhead with your MPI? Using syscall/sysenter?

syscall/sysenter only help to reduce the direct costs of a context switch but not the those caused by an increased number of TLB misses due to the the flush. In order to solve this problem a concept called 'address-space multiplexing' (which was originally designed by Jochen Liedtke, the founder of L4) is often used.
The basic idea is to divide the 4GB address-space into many smaller address-spaces using segmentation. That way, when a context switch occures, only some descriptors have to be reloaded which is much cheaper.

Another way to decrease context switch costs is to improve the performance of the IPC system which causes most switches. L4, which only supports non-buffered and synchronious messaging, has proven that the performance of IPC messaging can be increases dramatically compared to first generation microkernels like mach - not to mention monolithic kernels which basically suck at IPC performance.

For further details you might want to have a look at the official L4 website:
http://l4ka.org/

My main concern is understanding how hardware drivers are used and developed for a micro kernel environment, considering a few constructs I've seen do not have a "Hardware Manager" as part of their basic setup. This is baffling me.

Every operation system must have some sort of 'Hardware Manager' but there's no reason why it should be put into the kernel.

Device drivers need 2 ressources:
* IRQs
They are converted to IPC messages by the kernel which were sent by
'device tasks'. When an IRQ occures a messages is sent to all the driver
that have requested to be notified. The driver can then process the IRQ
and return to the kernel by sending a message. It's the kernel's job to
release the IRQ line.

* Address-space (memory mapped I/O, Ports)
L4 supports 3 primitives to deal with address-space management:
- task A can allow task B to access one of its page (map)
- task A can take away the access right it has given to task B (unmap)
- task A can give (away) one of its pages to task B (grant)
Memory is protected using paging, ports using the I/O bitmap in the TSS

A 'hardware-manager' should be implemented as a normal user-space task which was given the access right to all IRQs, all Ports, and all memory needed for I/O. The hardware manager can now load a device driver and pass on the neccessary access-rights to it.
This is much more flexible than using a built-in 'hardware manager' because the kernel doesn't have to know anything about drivers at all - it just manages some access-rights.

The basic idea in any microkernel is to only offer mechanisms but leave the policies to user-managers. With this concept even typical kernel tasks like memory managent or scheduling can be done in user-space.

regards,
gaf

[theubu]

gaf,

Thanks for the insight I will us it as a consideration in my planning... also thank you for that link I will research it a bit... it does sound very useful...


Are you working on a microkernel project yourself?

[bregma]

My main concern is understanding how hardware drivers are used and developed for a micro kernel environment, considering a few constructs I've seen do not have a "Hardware Manager" as part of their basic setup. This is baffling me

Mac OS X is a microkernel-based OS. All drivers are loadable modules, each responsible for autodiscovery of their driven hardware and self-registration in the ioregistry. There is a heirarchy of drivers matching the heirarchy of the hardware (eg. a PCI driver has PCI device drivers as children) within the ioregistry.

The kernel is responsible for providing resources (interrupts, memory addresses) for the drivers and for invoking the autodiscovery and autoregistration phase during a transition (power transition, hotplug, module reload), and for providing access to the ioregistry for applications, but each driver runs as a separate task and only IPC is necessary for an application to access a device.

[gaf]

Are you working on a microkernel project yourself?

Yes - I'm one of the programmers from the trion project which was founded on this board roughly 1.5 years ago. Unfortunately we didn't make that much progress lately - basically because designing a *real* OS is somethink completly different than writing some small and unstructured kernels to demonstate things like MM or task-switching.
When we started coding trion we did it just the same way, but once all the trivial stuff (pmode, basic paging, etc) was done and decissions about the over-all design had to be taken we found out that this would lead to a bloated monolithic kernel which is not what we wanted.
The design process that follwed ate up a lot of time but I'm optimistic that we'll be able to finish it within 1-2 months and then start coding again...

trion.sourceforge.net - website (under construction)
www.sourceforge.org/projects/trion - sourceforge account

regards,
gaf

[theubu]

gaf,

Cool I will check this out.... and I know what your saying my team did like 4 rewrites do to poor planning but it was final done...sorta but I may redesign or jump on board a new project to go micro kernel

[Pela Kiu]

Hello, I'm intrested in L4. I don't understand how drivers are implemented in UserSpace. If the port are mapped in memory it's easy to map/grant that page to the task, but what if it's not mapped-i/o. I mean the INB and OUTB functions are permitted in UserSpace? and if not how it's done in L4?

[carbonBased]

In this case, an Intel system is quite nice in that, yes, ports can be input/output in userspace.

Each task can have an extension of the TSS which contains a bitmap of all possible ports it can access from P3.

In my microkernel, drivers acquire resources through the kernel resource manager. Ports can then be accessed through special functions... in intel, these special functions would simply be in/out commands. Other platforms might require a context switch.

As far as other resources... memory is mapped into the userspace, and irqs are sent to drivers registered for them through message queues.

--Jeff