OSDev.org

Hi

http://www.anandtech.com/mac/showdoc.aspx?i=2436

this page in this article:
http://www.anandtech.com/mac/showdoc.aspx?i=2436&p=7

I know this isn't the usual place that contentraits on OS theory, but if what this guy is correct MacOS X/Darwin is a bit of a mess. A Mach 3 microkernel inside a FreeBSD wrapper etc. It seems to go totally against the ideals of keeping things simple. No wonder the server performance is so poor.

IMHO this is a way not to do it. Either go with a FreeBSD monolith or Mach microkernel, but not both at the same time.

srg

Agreed, it sounds like quite a soup in OS X. Not that Mach was a very good example of a microkernel to begin with...

Something I read in the article that caught my eye:

It also must be remarked that, for example, Linux is not completely a monolithic OS. You can choose whether you like to incorporate a driver in the kernel (faster, but more complex) or in userspace (slower, but the kernel remains slimmer).

Is this true, or is the author confusing the use of kernel modules with user-space drivers?

Colonel Kernel wrote: Is this true, or is the author confusing the use of kernel modules with user-space drivers?

Author is confused. Linux modules operate in ring 0 (A buggy driver still gets to kill the system). It's not a particularily dynamic module system either. The Nvidia kernel module, for example, needs to be rebuilt every time the kernel is compiled with a new configuration (AFAIK The Windows model is much more flexible).

User-space drivers (Eg The NDIS wrapper) are something totally different and use various kernel modules to interact with devices.

Just because there's module loading/unloading doesn't change the fact that the kernel is monolithic.

Hi,

Curufir wrote:Just because there's module loading/unloading doesn't change the fact that the kernel is monolithic.

This is a matter of opinion (i.e. I'd suggest the article's author had a different opinion of what is and isn't monolithic, and wasn't entirely wrong).

Consider a CPU that doesn't have privilege levels, where all software runs at the equivelent of "CPL=0". Would it be impossible to write a micro-kernel for this CPU? If an existing micro-kernel was ported to it, would that micro-kernel suddenly become monolithic with dynamically loaded device drivers, simply because there are no privilege levels?

What if I took a micro-kernel and modified the GDT entries so that all code ran at CPL=0? Surely the difference between micro-kernel and "monolithic with dynamically loaded device drivers" is more than the setting of a couple bits...

IMHO the difference between monolithic and micro-kernel has more to do with OS design than actual implementation details. I'd suggest that Linux (depending on how it's compiled) is "mostly monolithic with some micro-kernel features" - not purely monolithic or purely micro-kernel. The author's words "It also must be remarked that, for example, Linux is not completely a monolithic OS." does not seem confused to me.


Cheers,

Brendan

My views on the matter is that kernel modules absolutely do not make a kernel into a microkernel, they make the kernel into an extendable monlithic. The monolithic kernel is a kernel where everything is in the kernel, modules do not change this fact, in fact modules make it even "worse" as they add even more things to the everything else that the kernel already does increasing the overall monolithic-ness. If you start with a monolith of rock and brick-up around it that does not change the fact that it is still a monolith.

A microkernel should have clear divisions between components, this means it would be very difficult to have an extendable microkernel without putting the kernel at risk of having an Apache module attached to it along with a 3rd party TCP/IP stack which would definitely break the "criticial stuff that must be CPL0" model. It does seem to be difficult to define a microkernel, but a generic description would be that the OS features are divided into logical components which are each given their own service with well defined interfaces (GUI, Video, Audio, Input, Printing, Networking, Filesystem, etc). Where they run isn't specifically important, it just would be taunting fate to run them in the kernel address space.

About the priviledge levels, you could technically implement a microkernel on a CPU without priviledge levels, it would just yield minimal benefits. The stability is damaged, although not destroyed, provided you don't implement hacks where you modify service's address space directly, security is definitely destroyed though as any process can seize complete control.

One example of a microkernel OS on a CPU without privledge levels is Minix running on an 8086.

Anyway, back on topic, It's almost like they had no real direction with MacOS X (mono or micro), so tried to go both ways, or at least bolt on UNIX compatiblity on to Mach (how compatible with POSIX and UNIX is Mach anyway, I know not much about it). It also seems that the UNIX design rules of "Do one thing and do it well", or at least "Keep it Simple Stupid!!" were thrown out of the window. As Apple wasn't in the *nix world (AFAIK) could their input into the OS have caused this?

srg

It might be worthwhile to note that Mac OS X is a re-hashing of NeXTSTEP, which was also Mach-based, with elements of 4.4BSD IIRC.

So, if you want to ask why Apple made the choice, you might as well ask, why did NeXT do so in the 80s? Probably, it was just that Mach was very trendy back then.

Hm.

"MacOSX is a re-hashing of NeXTSTEP".

Not surprising, since NeXT was Steve Jobs' baby while he was out of Apple and MacOS X came into play a couple of years after he came back

"Linux has modules hence it is microkernel".

Don't quite agree. A microkernel has usually a small API which all other components will use to communicate among each other (be it messages or whatsoever). When you load a module, you barely add symbols to a table so that other modules can call your functions and lookup a table so that you can call other's functions. You cannot set up any restriction on what calls what, you cannot discover what's available (e.g. dependencies needs to be resolved at compile-time, even for modules)

"Is MacOS X / Darwin / FreeBSD / Mach a complete mess"

Maybe. Maybe not. The advantage of that layering is that you can get the level of abstraction you need for a certain purpose. I'm not 100% certain about the "slower user-level threads" as the author claims. MySQL/Appache have been fine-tuned to Linux behaviour for couple of years now. One shouldn't expect to have great performances by just recompiling a fine-tuned application on a new platform! To have a serious check, the author should have at least compared results of Appache/MacOSX/PowerG5 over Appache/Linux/PowerG5, if you ask me. And probably checking Appache/FreeBSD/PowerG5 should have been interresting too.

Now, let's make it clear: if you're just interrested in a fast MySQL server, there are little chance you want MacOSX anyway. MacOS's main strength is its user-friendliness (and multimedia dedicated programs) and servers usually don't mind friendliness at all!

Some interesting comments on the original article:

http://arstechnica.com/journals/apple.ars/2005/6/5/452
http://arstechnica.com/reviews/os/macosx-10.4.ars/4

The only acceptable distinction between microkernels and monoliths that I've ever heard, and that holds even in presence of architectures without any hardware protection, is the one based on communication. It goes like this:

A microkernel is a small nucleus that provides enough services for different servers to co-exist and communicate with each other, in order to implement rest of the required operating system services.

What services are enough? That depends on the exact design of the system. In many system that includes some form of security service. Almost every system has some form of IPC. Many have at least some memory management as well.

What exists inside kernel space has nothing to do with this. QNX is example of a microkernel system. Still, QNX runs a process manager inside kernel space. Even if it's running inside kernel space, it's still a "regular task", because it communicates (mostly) like everybody else.

Personally, I see the difference between a "kernel level task" (which a microkernel can admit just fine) and a "kernel module" (which is more of a modular monolith thing) as an issue of communication. In a microkernel systems "kernel level tasks" are usually just an optimization; normal tasks running inside the kernel for the purpose of making them faster. They use (a restricted set of) essentially the same APIs they would use from userspace.

A kernel module on the other hand is fundamentally part of the kernel; it is not a service running inside kernel, but an extension of the kernel to provide a new service. It plugs into a special kernel module API, often having access to lots of internal mechanisms that a "mere" kernel level task wouldn't dare to dream of.

Personally I have been thinking of having a kernel level task system for my microkernel, that would basicly work by simply linking the task with a kernel level library instead of the normal one. A normal userspace service could run inside kernel (after relinking) as long as it was happy with a limited set of library services.

In fact, this would even allow the kernel to refuse some task and simply run it in userspace instead. Theoretically even dynamic promotion/demotion would be possible. Say, attaching a debugger into a kernel level task could demote it (temporarily?) to user-level in order to make it safer to debug it.

mystran wrote:Still, QNX runs a process manager inside kernel space. Even if it's running inside kernel space, it's still a "regular task", because it communicates (mostly) like everybody else.

Not sure about that... I always thought the QNX Process Manager runs in user mode. In the end though, this is the only source I have to go on:

The Process Manager works closely with the Microkernel to provide essential operating system services. Although it shares the same address space as the Microkernel (and is the only process to do so), the Process Manager runs as a true process. As such, it is scheduled to run by the Microkernel like all other processes and it uses the Microkernel's message-passing primitives to communicate with other processes in the system.

Sharing the same address space doesn't necessarily imply that it runs at the same privilege level...

Well, AFAIK it does share the priviledge level as well.

Where did you find that info? I'm always interested in discovering the "inner secrets" of commercial OSes...

Plus it might affect how I design my own microkernel.

Some more clues here:

It's important to note that threads executing within procnto invoke the microkernel in exactly the same way as threads in other processes. The fact that the process manager code and the microkernel share the same process address space doesn't imply a "special" or "private" interface. All threads in the system share the same consistent kernel interface and all perform a privity switch when invoking the microkernel.

Especially the last sentence.

http://www.qnx.com/developers/docs/mome ... /proc.html

That one tells you that process manager actually lives inside the "system process", which is the upper portion of the address space (on most architectures). Now, since we know that QNX uses paging for memory protection, we can infer that:

1. to protect the "system process" from other processes, it must only be accessible by "supervisor" mode.
2. since process manager lives inside the "system process" it must have access to the "system process".
3. since CPL1/2 are nonportable and useless for page-level protection, the process manager needs to be either CPL0 or CPL3
4. it is quite safe assumption that they won't bother tweaking the MMU on every switch to/from the process manager.

I'd claim that together these imply that process manager runs in CPL0.

But the point they make about the interface is exactly the point I tried to have: process manager is still a "regular task" even ask a CPL0 thing, because it communicates with other tasks in exactly the same way as it would communicate, if it was a userlevel task.