OSNews

Well Microsoft Windows Vista may not be a microkernel, but it is doing a lot of simular things and I think that is great.

Most of all the drivers are now in the UserMode and 64-bit Vista has a different core even. I think Microsoft is moving in that direction starting with Vista and even in 64-bit mode they are moving even faster in that direction.

o Drivers can crash and not crash the OS (just restart and go). Vista may be able to restart automatically.
o Drivers can be upgraded without rebooting.
o Drivers can be easier to create(program) in usermode.
o Drivers can be easier to test in usermode.

But...but what about those of us that like Vi and TABS????

Well.. you guys are just freaks... nobody likes you.

I'm not sure why the parent was downmodded so swiftly. Please notice the sarcasm in his comment; I see it as an attack to the OS holy wars. Let's try not to be so obtuse.

IIRC, the reason OS X is measurably slower at some tasks is because of the microkernel factor. (I seem to remember some sort of kerfluffle about X serves and SQL queries.)

OSX is not a true muK by academic standards. It is a "modified microkernel" (in much the same way as the Windows NT kernel is, which is also sometimes mislabeled as a muK). It does not at all work the way Thom's article describes, as the BSD server makes direct function calls into the kernel and does no message passing at all. It is for all intents and purposes a monolithic kernel.

If your interested in how OSX is designed under the hood, read the paper at the following url:

http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_h...

Galvanash, thanks for the link. Fascinating read. I wasn't aware of the extent to which the OS X kernel had evolved away from being a microkernel.

'the legendary stability of QNX'
Not only is it damn stable, but I have found it to be very fast. Runs off a CD almost as fast as from the HDD as well. Talking about QNX Neutrino 6.2.1.

"Where are my clothes?! Wait. Whose bathtub is this?"

Nah, Martini's different. More like: "Thom, did we really get kicked off of a graveyard last night?" "Yes..." while thinking, thank god girl you didn't mention that other thing in front of this 30-man crowd that together composes my social life...

:/.

There has been talk in nanokernels of making the scheduler user-space to so that different apps could use different schedulers. For example there could be problems with not being MP-safe so you'd want to have finer control, or some legacy code that makes certain exceptions, or a myriad of other reasons.

The timer has to be in the kernel. How else would the scheduler function?

Cooperatively? Don't laugh. That's an option and if you can plug-in various schedulers it could be useful, especially for something like Wine emulating Windows 3.11, or if you have some real time (RT) tasks and non-RT. Where you could put the on-RT scheduler as a process with the RT-scheduler.

I don't recall where I read this, but I believe it was in some paper on a branch of the L4 project.

file system in user-space adds no benefit: if it crashes, how can you restart it?

I don't see the problem. Just restart and block and process that makes an I/O until it's back a running.


If the memory manager bails out, how can you create a new process and allocate memory for it?

Kill any process allocated by that manager, but any app controlled by another can continue living. You could make an ultra-stable manager for essential functions, and a more powerful-but-complex-so-harder-to-debug one for user apps.


what about a diskless-workstation that boots from an NFS export? What would happen if the networking subsystem crashed

Well it could run off the data it has in memory and/or just block until the connection is re-established. You could have a process that stores the details of your account monitor the connection process, and when the connection dies have it refeed the data that is needed to regain passwords.

I don't see the problem. Just restart and block and process that makes an I/O until it's back a running.

Usually, restarting a process involves reloading the binary from disk, so if the file system is just to get restarted, how can you load it back from disk to memory? You could keep its text in memory, but what about corrupted data structures?

I still don't see any advantages of a microkernel system. Just look at Windows NT 4.0 and how they integrated back the graphic drivers back into kernel space due to performance problems. The fact is that, in Windows NT 3.5, a crash in the graphics subsystem left the system unusable. Well, it could keep serving files, but it was impossible for anyone to log in to the system.

There's a misunderstanding here. The fault handling that supposedly comes from microkernels isn't keeping the failure of a component from causing the system to fail. Rather, it's keeping the failure of a component confined within that component.

All microkernels do, from an architectural point of view is enforce fault confinment through the use of seperate address spaces.

The problem is that the cost they introduce to provide that separation is higher (usually *much* higher) than the benefit gained.

Not having a stable kernel API means constant source code maintenance - you can't write a piece of software this week and know that it will still work next week because someone might change the kernel API on the weekend.

Good ganja?

You should consider sharing your views with GNU. Who would've thought they'd be wrong?

Drivers, modules, etc. can very will become proprietary with a monolithic GPL kernel. Infact, there only about a dozen examples for Linux.

There is currently nothing preventing the making of drivers and modules closed source. As long as they aren't distributed with the kernel then the GPL doesn't apply.

- Jesse McNelis

Linux is dead in the water for consumer boxes if you want EVERYTHING to be open source.
What you say holds true if everyone plays along.
Additionally, in the same spirit of your sentiment, only men could vote in the US until the 19th Ammendment.

I have to agree with felipe_alfaro. On technical merits alone, microkernels stomp monolithic kernels into the ground. In practice (and code) it is the other way around.

When you say in practice are you refering to those of AmigaOS, MorphOS, AROS, QNX and many others? I always liked best the idea and practice of micro kernels

I am politely saying that Linux which is a monolithic kernel, beats every supposed microkernel I can personally find. Andrew Tannenbaum (whom I deeply respect) says microkernel design is better and I don't disagree with him. However, his code (minix 3) is still inferior from many angles versus the Linux kernel. Is there a microkernel that even matches the Linux kernel performance wise?

I somehow doubt I will ever see a microkernel that will come close to the speed of RTLinux (realtime linux).

I am really trying to not start a flamewar here.

I somehow doubt I will ever see a microkernel that will come close to the speed of RTLinux (realtime linux).

QNX's Neutrino kernel. QNX is probably the most advanced muK system out there.

hmm, a real-time os. while im not fully up to speed, whats the performance of a linux kernel rigged for real time running?

Works fine in NetPositive. Your Firefox is broken

After further investigation I see OSNews does not work if It does not get the Referrer header, Which I do not send.

Please take note that ring0 and ring3 are Linux-only terms, and meaningly outside discussions of the Linux kernel only. Besides, the NT Kernel and Mac OS X kernel aren't monolithic, but hybrid.

Please take note that ring0 and ring3 are Linux-only terms, and meaningly outside discussions of the Linux kernel only

LOL, read the Intel manuals dude - it's OS-agnostic term meaning "privilege level", and has roots in MULTICS (IIRC it had 8 od them

Besides, the NT Kernel and Mac OS X kernel aren't monolithic, but hybrid.

Wrong again - NT is even more monolithic than Linux, since it has GUI (win32k.sys) in kernel-mode. Read the relevant literature (Solomon/Russinovich for examble).

As for the MacOS - it does contain the Mach microkernel - but, as I said, it's not used as a microkernel. See what the author of upcoming "MacOS X Internals" book says on this topic:

http://www.kernelthread.com/mac/osx/arch_xnu.html

XNU's Mach component is based on Mach 3.0, although it's not used as a microkernel. The BSD subsystem is part of the kernel and so are various other subsystems that are typically implemented as user-space servers in microkernel systems.

The term "hybrid microkernel" is IMHO just a marketing propaganda dating from mid 1990s when NT 4.0 was released. NT is even more monolithic than traditional UNIXen.

Wrong again - NT is even more monolithic than Linux, since it has GUI (win32k.sys) in kernel-mode. Read the relevant literature (Solomon/Russinovich for examble).

Wowwow there, NT is a hybrid kernel. It started out as a true muK (Tanenbaum even compared MINIX to NT), but slowly but surely more things were added into kernelspace. The fact that the GUI is placed in kernelspace does not change the fact that NT is a hybrid kernel. Wikipedia has this to say on it:

"The architecture of the Windows NT operating system line is highly modular, and consists of two main layers: a user mode and a kernel mode. Programs and subsystems in user mode are limited in terms of what system resources they have access to, while the kernel mode has unrestricted access to the system memory and external devices. The kernels of the operating systems in this line are all known as hybrid kernels as their microkernel is essentially the kernel, while higher-level services are implemented by the executive, which exists in kernel mode."

http://en.wikipedia.org/wiki/Architecture_of_the_Windows_NT_operati...

And with Vista, a lot of parts are moved out of kernelspace again, back into userspace where it belongs. So when Vista comes, the NT kernel has grown more towards its muK origins.

Wowwow there, NT is a hybrid kernel. It started out as a true muK (Tanenbaum even compared MINIX to NT), but slowly but surely more things were added into kernelspace.

No, NT is NOT a microkernel, and was never designed to be one. It has

1) ring0 drivers
2) all non-essential kernel services, which are traditionally implemented as user-mode (ring3) servers in pure microkernels such as Mach, are in ring0
3) it has even super-nonessential stuff in ring0 such as GUI, traditionally in ring3 on *NIX

There is no way to communicate between, lets say, Memory Manager and the Scheduler via formal IPC (msg_send() and msg_receive() in Mach) - they are ALL inside one statically compiled nonseparable module.

Wikipedia article is somewhat clueless, and paradoxical IMHO:

The kernels of the operating systems in this line are all known as hybrid kernels as their microkernel is essentially the kernel, while higher-level services are implemented by the executive, which exists in kernel mode.

So it basically this sentence says: kernel = microkernel, but upper-level services are still ring0, like the microkernel itself :-)

But if both higher-level services and the "microkernel" are in the same privilege level, they must be in the same address space, meaning no protection, no security, no mutual IPC - ie. no microkernel design at all

As i said - calling NT a hybrid microkernel is just a marketing propaganda from the 90s, when the term microkernel was hot stuff.

"...and has roots in MULTICS (IIRC it had 8 od them "

Actually 16, but then again, they didn't actually use all of them

Actually, it did had 8 hardware rings

http://www.multicians.org/mgr.html#ring

It's really funny that most OSes today are still being built on 1960s technology

ring0 - ring3 are intel terminology. x86 have 4 privilege rings, whereas most processors only have 2 (kernelmode and user mode). This is where the terminology comes from, not Linux.

"Please take note that ring0 and ring3 are Linux-only terms"
Uh, no. They are operating system design terms where the actual number of rings depends on the processor.

"Besides, the NT Kernel and Mac OS X kernel aren't monolithic, but hybrid."
Agreed, and so is the Linux kernel.

You say that like it's a good thing, but hybrid is the worst of both worlds. All the overhead of message passing with all of the memory collision issues of single address space.

And the cons against microkernel? Spending most of your CPU cycles doing context switches and IPC for simple stuff such as page fault handling and ISR dispatching.. That's the reason why there are NO general-purpose commercially-successful microkernel OSes - that's right, all Win NT-based, Linux, *BSD, Solaris, HP-UX, AIX, MacOS (aka Darwin - it contains Mach but it is not used as a microkernel, there are the FBSD, IOKIT and drivers stuff in ring0 too!) are monolithic. And those who aren't, (QNX, EKA2 - SymbianOS nanokernel) are so not because of the "increased stability and security", but because it enables them to have predictable interrupt latency.

I know, I know, that's one of the reason all *miga OSs out there feels so slow... :roll:

If you want performance, you'd be better off using exokernels anyway. I'm surprised this hasn't escaped from academia yet.
Don't let EyeAm hear you!

Maybe, but I'm not convinced: spreading the work too thin can be a pitfall of parallelisation: CPU contains cache and if a system request goes to several CPUs in a micro-kernel, there could easily be data shared between CPU increasing cache-contention, which reduce efficiency.

Schedulers tries to put related thread on the same CPU, while at the same time balancing the load, this is a tricky balance and I'm not sure micro-kernel helps here.

Yep, doing too much of something can be even worster than doing nothing.

Part for all naysayers about monolithic tree
On the other hand (at least in my simple mind)
Monolithic kernel could simply put out generic `muK` protocol handlers (drivers) that would act on and control outside drivers, like for example `muK` network adapter handle and provide complete protocol needed. This driver would need to act as protocol server and handle the pluged outsiders.

Hierarchy of Linux kernel is just a file system, nothing else. So why couldn't some drivers provide external `muK` capabilities?

Something being monolithic doesn't mean it couldn't be extended with some sub branches that would provide `muK` protocols and handling. Now, one network driver provides and can control few network cards that are in his domain. This would just control more generic domain.

But in my daily reality.
I don't miss microkernel a bit. So far NVidia driver was the only one I ever installed so far. I just buy most compatible machine that suits my needs and that's it.

A microkernel does not inherently make better use of
multiple CPUs than a monolithic kernel. Often quite the
reverse, in fact.

A monolithic kernel isn't a single "process" or
"thread" (although there can be threads that run solely
in kernel mode). The kernel is called by, and performs
work on behalf of, user processes.

Now say that we have a 16 CPU system with 1 user
process on each CPU and each one would like to allocate
a page of memory. The kernel is notified about this
allocation request somehow (via a page fault, usually),
then asks the memory manager to find a page, return it
to us.

In the Linux kernel, in the common case, all processes
can concurrently enter the memory manager, and none
will have to take a lock which blocks another, because
each can just take a page from per-CPU freelists.

In a microkernel, there would be 16 requests queued up
for the memory manager process, which runs on one CPU
and processes them one at a time. If you would like to
have 16 memory manager threads, then they can now run
concurrently, but they will still block one another
when taking IPC requests off the queue.

Actually, the memory manager *is* something that a high
performance microkernel is likely to multi-thread
and/or put a light-weight per-CPU allocator in front of
the IPC call (oops, no longer a microkernel!)

When you start talking about MPs, you have to be careful to distinguish between the two strategies of MP resource scheduling design. While it is common, especially the first time an OS is ported to an SMP to have a 'big kernel lock' and funnel all requests to a certain processor, that's an implementation detail and not an artifact of micro versus macro kernel.

No that's got nothing to do with what I was talking
about.

I just provided an example to illustrate why a micro
kernel is not inherently more SMP scalable than a
monolithic kernel.

In other words, a monolithic kernel can be just as
threaded / scalable as any microkernel.

The problem is that on paper everyone's block diagram of their system looks modular and elegant. In practice, microkernels don't give you any modularity. They simply throw more of the crap outside the 'kernel' than was in it before. It's the same crap in a different bag. But now it has all the extra overhead of talking to the microkernel to get things done.