Linked by Thom Holwerda on Sun 16th Apr 2006 15:36 UTC
OSNews, Generic OSes Right in between a car crash and Easter, I knew I had to write a Sunday Eve Column. So here I am, digesting vast quantities of chocolate eggs (and I don't even like chocolate), craving for coffee (for me about as special as breathing), with the goal of explaining to you my, well, obsession with microkernels. Why do I like them? Why do I think the microkernel paradigm is superior to the monolithic one? Read on.
Order by: Score:
QNX
by mOOzilla on Sun 16th Apr 2006 15:55 UTC
mOOzilla
Member since:
2006-04-11

Hot configurable, plugable and easier to develop for without giving away source (Gfx drivers perhaps)

Reply Score: 1

RE: QNX
by proforma on Tue 18th Apr 2006 05:07 UTC in reply to "QNX"
proforma Member since:
2005-08-27

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.

Reply Score: 1

Oh yeah!
by sigzero on Sun 16th Apr 2006 16:11 UTC
sigzero
Member since:
2006-01-03

Well I like Vi and spaces over emacs and tabs! So there!

Reply Score: 2

RE: Oh yeah!
by DoctorPepper on Mon 17th Apr 2006 18:11 UTC in reply to "Oh yeah!"
DoctorPepper Member since:
2005-07-12

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

Reply Score: 2

RE[2]: Oh yeah!
by egarland on Mon 17th Apr 2006 20:42 UTC in reply to "RE: Oh yeah!"
egarland Member since:
2005-08-05

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

Reply Score: 1

v Well my OS is better than your OS
by mOOzilla on Sun 16th Apr 2006 16:16 UTC
espinafre Member since:
2006-01-15

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.

Reply Score: 1

OS X, QNX, and Tomfoolery
by kadymae on Sun 16th Apr 2006 16:18 UTC
kadymae
Member since:
2005-08-02

However, I think the circumstances have changed a lot since those days. Monolithic made sense 16 years ago, but with today's powerful computers with processors acting as $300 dust collectors most of the time, the advantages of a muK simply outweigh its inevitable, minute, and in user experience probably immeasurable, performance hit.

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.)

But, on the other hand, there is the legendary stability of QNX.

(in the Netherlands, we say, 'automatic is for women'; no offence to the USA where automatic gearboxes are much more popular, since you guys across the pond have longer distances to cover)

Y'know, that statement really implies that women are inferior. Next time you see a guy push a small person out of a tight orifice, let me know. ;)

And the reason we have so many automatics over here, is that the US generally has non-existant public transportation, which makes for long slow commutes, and 90 minutes of stop and go with a manual gearbox will have your left knee screaming in pain.

(BTW, I drive standard transmission.)

it's why I prefer a straight Martini Bianco over weird cocktails (again, the end result is the same, but I'll leave that up to your imagination)

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

Reply Score: 5

RE: OS X, QNX, and Tomfoolery
by galvanash on Sun 16th Apr 2006 16:34 UTC in reply to "OS X, QNX, and Tomfoolery"
galvanash Member since:
2006-01-25

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...

Reply Score: 5

RE[2]: OS X, QNX, and Tomfoolery
by kadymae on Sun 16th Apr 2006 17:27 UTC in reply to "RE: OS X, QNX, and Tomfoolery"
kadymae Member since:
2005-08-02

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.

Reply Score: 1

RE: OS X, QNX, and Tomfoolery
by Slapo on Sun 16th Apr 2006 16:46 UTC in reply to "OS X, QNX, and Tomfoolery"
Slapo Member since:
2005-07-06

'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.

Reply Score: 3

RE: OS X, QNX, and Tomfoolery
by Thom_Holwerda on Sun 16th Apr 2006 17:22 UTC in reply to "OS X, QNX, and Tomfoolery"
Thom_Holwerda Member since:
2005-06-29

"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...

:/.

Reply Score: 5

v RE: OS X, QNX, and Tomfoolery
by rapont on Mon 17th Apr 2006 01:00 UTC in reply to "OS X, QNX, and Tomfoolery"
Sounds great, but still...
by jjezabek on Sun 16th Apr 2006 16:19 UTC
jjezabek
Member since:
2005-08-07

Someone/something has to do the hard stuff. Imagine a userspace driver, which doesn't crash, but for some reason writes garbage to your screen. It can't get automatically restarted, because from a microkernel POV everything is in best order. So you either have to restart the server using a remote machine (and hoping that the NIC driver is fine) or simply reboot. I'd say most users will go for the second option.
So - a buggy driver in userspace isn't much better than a buggy driver in kernelspace.
But yes, I agree, writing drivers in userspace is probably way less difficult than in kernelspace; that's probably the single most important difference.

Reply Score: 3

Timer
by _tef on Sun 16th Apr 2006 16:24 UTC
_tef
Member since:
2006-04-16

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

:D

Reply Score: 5

RE: Timer
by CaptainPinko on Sun 16th Apr 2006 18:43 UTC in reply to "Timer"
CaptainPinko Member since:
2005-07-21

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.

Reply Score: 3

Microkernels in theory and practice
by felipe_alfaro on Sun 16th Apr 2006 16:28 UTC
felipe_alfaro
Member since:
2006-04-16

The problems with microkernels is than, in theory, they really look good. However, in practice, running a file system in user-space adds no benefit: if it crashes, how can you restart it? If the memory manager bails out, how can you create a new process and allocate memory for it? The networking subsystem is a good candidate for a user-space subsystem, but what about a diskless-workstation that boots from an NFS export? What would happen if the networking subsystem crashed?

More and more pieces of Linux are being pushed out to userspace. One nice example is used, of FUSE. udev is a central place in Linux device management, but even if it crashes or malfunctions, you can revert to the well-known mknod tool.

Reply Score: 5

CaptainPinko Member since:
2005-07-21

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.

Reply Score: 1

felipe_alfaro Member since:
2006-04-16

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.

Reply Score: 3

Cloudy Member since:
2006-02-15

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.

Reply Score: 3

A very good article...
by Brendan on Sun 16th Apr 2006 16:31 UTC
Brendan
Member since:
2005-11-16

Some notes:

The "clock" is probably a source of periodic interrupt used by the scheduler for pre-emptive task switching and timing (things like a "sleep()" function). It probably has nothing to do with "time and date". Because the scheduler relies on this clock (and everything else relies on the scheduler instead of this clock), building support for it into the microkernel is a very sane thing to do.

A micro-kernel is not necessarily "fail-safe". For example, if the hard disk driver crashes then you'll loose all of the data stored in swap space, and having a micro-kernel won't help to retrieve it. Another example would be the virtual file system - if it crashes then any software that was relying on it will loose their open file handles, etc. The same applies to everything that retains "client state". With a lot of work a micro-kernel can be more "fail-safe", but you need systems in place to take care of each type of failure. Without these extra systems it's not much better than a monolithic kernel (of course "protection" is a different subject).

Reply Score: 4

Well my OS is better than your OS
by mOOzilla on Sun 16th Apr 2006 16:37 UTC
mOOzilla
Member since:
2006-04-11

Come on get some humor implants! It was a joke!

Reply Score: 0

v Bypassing Windows Authentication check
by mOOzilla on Sun 16th Apr 2006 16:38 UTC
The ONLY way to ensure GPL
by stephanem on Sun 16th Apr 2006 16:40 UTC
stephanem
Member since:
2006-01-11

Is to have a monolithic kernel because as soon as you move to a muK, drivers, modules, filesystems all can become closed source - you are forced to export a "stable" kernel API that Linus and co JUST WON'T DO

Reply Score: 2

RE: The ONLY way to ensure GPL
by Brendan on Sun 16th Apr 2006 16:52 UTC in reply to "The ONLY way to ensure GPL"
Brendan Member since:
2005-11-16

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.

Reply Score: 1

RE: The ONLY way to ensure GPL
by JMcCarthy on Sun 16th Apr 2006 17:13 UTC in reply to "The ONLY way to ensure GPL"
JMcCarthy Member since:
2005-08-12

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.

Reply Score: 3

RE: The ONLY way to ensure GPL
by jessta on Mon 17th Apr 2006 04:21 UTC in reply to "The ONLY way to ensure GPL"
jessta Member since:
2005-08-17

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

Reply Score: 2

v Closed drivers are evil?
by mOOzilla on Sun 16th Apr 2006 16:42 UTC
RE: Closed drivers are evil?
by smitty_one_each on Sun 16th Apr 2006 23:54 UTC in reply to "Closed drivers are evil?"
smitty_one_each Member since:
2005-07-07

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.

Reply Score: 1

needs more cowbell
by SEJeff on Sun 16th Apr 2006 16:46 UTC
SEJeff
Member since:
2005-11-05

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.

The #1 problem with the microkernel design... can we say latency? With any microkernel, the latency issue is horrendous. XNU, the kernel in Mac OS X, doesn't have as much of a latency issue because it is more hybrid than minix 3 or L4. I guess this makes XNU more of a hybrid microkernel, but not even minix 3 is 100% microkernel based. Scheduling and race conditions can also be more of an issue in microkernels as everything runs in userspace.

http://www.minix3.org/vmware.html minix 3 vmware player image

Reply Score: 2

RE: needs more cowbell
by Pixie on Sun 16th Apr 2006 17:56 UTC in reply to "needs more cowbell"
Pixie Member since:
2005-09-30

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

Reply Score: 1

RE[2]: needs more cowbell
by SEJeff on Sun 16th Apr 2006 19:27 UTC in reply to "RE: needs more cowbell"
SEJeff Member since:
2005-11-05

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.

Reply Score: 1

RE[3]: needs more cowbell
by Thom_Holwerda on Sun 16th Apr 2006 19:29 UTC in reply to "RE[2]: needs more cowbell"
Thom_Holwerda Member since:
2005-06-29

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.

Reply Score: 5

RE[4]: needs more cowbell
by hobgoblin on Mon 17th Apr 2006 03:21 UTC in reply to "RE[3]: needs more cowbell"
hobgoblin Member since:
2005-07-06

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

Reply Score: 1

RE[5]: needs more cowbell
by smitty on Mon 17th Apr 2006 06:24 UTC in reply to "RE[4]: needs more cowbell"
smitty Member since:
2005-10-13

I don't know, but it's important to remember: RTOS != High Performance OS. The important thing about a RTOS is predictable (and low as possible) latencies. It really doesn't matter what the overall performance is, though, which means a microkernel might be much more appropriate for a RTOS than one meant for servers.

Reply Score: 1

v needs more XML
by mOOzilla on Sun 16th Apr 2006 16:46 UTC
v OSNews is BROKEN
by mOOzilla on Sun 16th Apr 2006 16:57 UTC
RE: OSNews is BROKEN
by Sauron on Mon 17th Apr 2006 05:56 UTC in reply to "OSNews is BROKEN"
Sauron Member since:
2005-08-02

Works fine in NetPositive. Your Firefox is broken ;)

Reply Score: 1

RE[2]: OSNews is BROKEN
by mOOzilla on Mon 17th Apr 2006 08:26 UTC in reply to "RE: OSNews is BROKEN"
mOOzilla Member since:
2006-04-11

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

Reply Score: 1

And why I hate microkernels..
by ivans on Sun 16th Apr 2006 17:04 UTC
ivans
Member since:
2005-12-03

Oh joy. Here it goes again - the ever lasting story of how never-succesful academic bullshit called "microkernel" never made it into the mainstream OSes. And how world would have been a safer place, with no drivers fooling around in ring0, if Cutler/Torvalds/whomever had listened to mr. Tanenabaum and alike.

The microkernel propaganda is mostly composed of three common FUDs:

1) microkernels are more "stable", because having ALL kernel code besides scheduler/dispatcher, IPC and some basic interrupt routing in ring3 (aka user-mode)

WRONG. If any crucial OS component (such as Memory Manager or FileSystem driver) fails - the whole OS fails as well. Being in ring0 (like the monolithic kernels do it) makes it just crash faster.

2) microkernels are more modular/maintanable/simple/blahblah

Writing modularized code is the basic tenet of software engineering, and it's called separation of policy from mechanism, and has NOTHING to do with the kernel being monolothic or not.

For example - Linux kernel is highly modular, either from the standpoint of compile time flags, or dynamically expandable functionality via LKMs. Just look at the design goals behind the VFS(used by any filesystem driver) and LSM (Linux Security Modules - utilized by SELinux, DTE..) to know what I mean..

NT kernel (W2K, WS2K3, XP, Vista..) is also very modular - the basic kernel schedulable primitives are encapsulated into so-called "executive components" (MM, I/O, essentialy anything besides scheduler) but are still all being compiled into one big fat binary called NTOSKRNL.EXE. The point is that it's the code that separates different abstraction policies, not the postcompiled modules organization.

3) It's easier to write drivers for microkernel.

Because they should, by definition, be living in ring3, and could be debugged in gdb or VS, and not in null-modem connected kernel debugger :-) And that's the reason why printer drivers are in userland ever since W2K, why Vista will have so-called UMDF (User-Mode Driver Foundation) that will enable most, for OS nonessential, cheap hardware to have it's drivers running in ring3 (if you have XP SP2, check out the WDFMGR.EXE's process description ;)

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.

Sorry for bad english.

Reply Score: 5

RE: And why I hate microkernels..
by Ronald Vos on Sun 16th Apr 2006 17:16 UTC in reply to "And why I hate microkernels.."
Ronald Vos Member since:
2005-07-06

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.

Reply Score: 1

ivans Member since:
2005-12-03

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.

Reply Score: 5

Thom_Holwerda Member since:
2005-06-29

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.

Reply Score: 5

ivans Member since:
2005-12-03

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.

Reply Score: 5

Thom_Holwerda Member since:
2005-06-29

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

I'm sorry, but if I have to choose between believing you in saying NT did not start out as a muK, and andy Tanenbaum saying it did, I prefer the latter. No offense.

it has even super-nonessential stuff in ring0 such as GUI, traditionally in ring3 on *NIX

That's a subjective matter. A kernel is hybrid when it combines both worlds; some parts live in kernelspace, while others do not. Exactly what goes into kernelspace has absolutely nothing to do with it. You might argue that the desktop is not supposed to be in kernelspace-- but for a desktop operating system... I'd say the desktop is important and therefore giving it a speed bump by placing it in kernelspace makes sense. The reason the GUI does not live in kernelspace in UNIX is because, well, UNIX is not a desktop operating system. Using UNIX as a benchmark for defining how a desktop operating system should handle its kernel is like asking a butcher to explain to the bakery how to make bread.

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 ;)

Err... Exactly, because the NT kernel is indeed not a muK, it's a hybrid. And by hybrid one means that certain parts live in kernelspace, while others don't. And since NT is very flexiable and modular, they can move stuff in and out of kernelspace relatively easily (hence the GUI in Vista will live in userspace again).

Reply Score: 5

ivans Member since:
2005-12-03

I'm sorry, but if I have to choose between believing you in saying NT did not start out as a muK, and andy Tanenbaum saying it did, I prefer the latter. No offense.

Look Thom, I've read most of the available windows internals literature, even that leaked W2K source code, spent countless hours disassembling NTOSKRNL.EXE and even reported some kernel bugs to MS lately, and found absolutely no proof that NT was ever to be or has been a microkernel. Function calls between various executive components are so interleaved that there is absolutely no chance of decoupling them. Ever.

Noone questions Mr. Tanenbaum's authority on general OS design theory, distributed systems, compiler and automata theory etc. - but I think that in this case, he fell on MS's marketing crap. Heck, even Cutler said they're building something different from RSX-11M (which was a microkernel).

Read the relevant literature (Russinovich/Solomon is great for starters), or check out the discussions on this "microkernel issue" on comp.os.ms-windows.programmer.nt.kernel-mode.

That's a subjective matter. A kernel is hybrid when it combines both worlds; some parts live in kernelspace, while others do not. Exactly what goes into kernelspace has absolutely nothing to do with it.

Oh, it certainly has. "Hybrid microkernel" is in this context so vaguely defined term it can be applied on any OS you like. Let me put it like this: NT has inside kernel-mode (ring0) almost anything that traditional monolithic *nix kernels (Linux, Solaris, *BSD etc.) have + GUI. So can anybody tell me what the hell is so microkernelish about it, that other monolithic OSes don't have, so that it can be entitled as "hybrid microkernel"???


And since NT is very flexiable and modular, they can move stuff in and out of kernelspace relatively easily

No they can't ;) I would really like to see a hacker capable of putting, lets say, Object Manager, inside user-mode server process and routing all handle-checking logic via IPC on it :-)

(hence the GUI in Vista will live in userspace again).

I thought we've demistifyed that one..

http://osnews.com/permalink.php?news_id=13007&comment_id=74945

Reply Score: 5

Cloudy Member since:
2006-02-15

Tannenbaum's wrong on this one. Cutler et al started out designing NT along similar lines to VMS, which he had worked on at DEC. Early Microsoft documentation on the NT structure makes this non-microkernel architecture very apparent. About the time of the Seattle OSDI, Mach was gaining mind share, and Cutler came to OSDI with a presentation declaring NT to be "micro kernel based". It was, by far, the funniest presentation I've ever seen.

Early on, a "microkernel" system was thought to be one in which message-passing was used to separate functional subsystems. This comes from Mach's predecessors, especially Accent.

Mach was originally intended to be a "pure" message-passing mostly user space OS ala Accent, but DARPA demanded that Mach be Unix compatible if Rashid wanted DARPA funding. From this was born the BSD/Mach hybrid crap that ended up dying such a horrible death as OSF/1.

"microkernel" is a silly idea. It specifies an implementation technology (and one based on the hardware privilige model of a particular processor architecture at that) as a solution to an architectural problem.

That's the real reason why "microkernel" never made it out of academia into any widespread commercial use.

Reply Score: 3

Thom_Holwerda Member since:
2005-06-29

That's the real reason why "microkernel" never made it out of academia into any widespread commercial use.

And yet there is a muK operating system we all use, we all encounter basically daily: QNX. It powers a lot of medical equipment, cars, home theater equipment, satelites, the robotic arm on the space shuttle, etc.

In fact, QNX is one of the leading RTOS's as well as one of the leading embedded operating systems, so saying that the muK never made it out of academia is wrong.

Reply Score: 5

Cloudy Member since:
2006-02-15

I'm sorry, I thought we were discussing general purpose OSes.

The embedded universe (real embedded, not what's now coming to be called embedded) is a different beast with a different set of requirements.

QNX didn't start out as a "microkernel" -- it even predates Mach. It started out as a small well organized architecture for embedded applications. And it was well done. Also very much bare-boned.

It is the well organized architecture, and not the 'microkernel' that made QNX the market leader.

Do you, by the way, recall when QNX got around to adding 'microkernel' as a marketing bullet? 2001? when they were already, what, 20 years old.

QNX, by the way, is more like Brevix, in having a small set of base facilities, than it is like a traditional microkernel, because it does not rely on message passing.

Reply Score: 4

galvanash Member since:
2006-01-25

I'm sorry, but if I have to choose between believing you in saying NT did not start out as a muK, and andy Tanenbaum saying it did, I prefer the latter. No offense.

Mr. Tanenbaum never said that NT started as an muK. He would have had no way of knowing that. He was merely parroting what Microsoft was saying as they were promoting their new OS and he foolishly took them at their word. This was WAY before NT shipped btw... You might be interested to see what he has said since then:

http://www.cs.vu.nl/~ast/brown/followup/

Quote straight from the horse's mouth (about 3 quarters of the way down):

"Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0."

You can call it a "Hybrid" if you like, but that is nothing more than marketing bullshit. Hybrids are simply what companies call monolithic kernels to sound cool... ;)

Mr. Tanenbaum defines a muK the same way as most academics, a small kernel that does AT THE MOST memory management, scheduling, and IPC. EVERYTHING else, including all drivers, file systems, etc. should communicate with the kernel from userland. Period. By that definition neither NT nor OSX are even close to being microkernels.

Reply Score: 1

siride Member since:
2006-01-02

You clearly don't know what you're talking about. NT has sophisticated IPC mechanisms (such as APC and LPC) and most non-essential services live outside the kernel. The sole exception is win32k.sys and that's inside the kernel only in the sense that it lives in ring0. It's still it's own separate module that used to be in csrss.exe (which still exists as a microkernel style server, mainly for console apps).

The desktop is NOT integrated into the kernel. It's called explorer.exe and you can easily terminate it from task manager and use something else. A great deal of services run in usermode (ever seen the crapload of svchost.exe instances running?). Yes, the drivers run in kernel space, but this, like win32k.sys, is done for performance reasons and now that computers are fast enough, drivers and graphics will move back out into userspace in Vista.

Reply Score: 3

ivans Member since:
2005-12-03

NT has sophisticated IPC mechanisms (such as APC and LPC) and most non-essential services live outside the kernel.

But you're missing the point (i didn't say that NT doesn't have IPC, it's just NOT USED for communication between different kernel components, because they live in the same address space - the upper 2 gigs) - in microkernel "nonessential services" are anything but the scheduler/IPC.

YOU CANNOT SEPARATE ANY EXECUTIVE NT KERNEL COMPONENT INSIDE A USER-MODE PROCESS.

The desktop is NOT integrated into the kernel...

I didn't claim it was. You seem to be constantly proving something I didn't say, in order to apper correct in other things.

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

Anyway, I would like to hear in just which ways is NT more microkernelish than, say Linux? :-)

Reply Score: 5

hustomte Member since:
2006-01-07

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

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

Reply Score: 1

ivans Member since:
2005-12-03

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 ;)

Reply Score: 1

hobgoblin Member since:
2005-07-06

if its not broken, dont fix it...

Reply Score: 1

proforma Member since:
2005-08-27

>if its not broken, dont fix it...

If you have crap drivers pulling down your OS, then it is broken already.

Reply Score: 1

hobgoblin Member since:
2005-07-06

and may i ask what drivers that is? or for that matter what os one is talking about?

Reply Score: 1

bleurgh Member since:
2006-04-16

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.

Reply Score: 5

Soulbender Member since:
2005-08-18

"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.

Reply Score: 1

Cloudy Member since:
2006-02-15

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.

Reply Score: 1

RE: And why I hate microkernels..
by Pixie on Sun 16th Apr 2006 17:58 UTC in reply to "And why I hate microkernels.."
Pixie Member since:
2005-09-30

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:

Reply Score: 1

Microkernels can be fast/performant
by Ronald Vos on Sun 16th Apr 2006 17:12 UTC
Ronald Vos
Member since:
2005-07-06

For example Exec is mentioned on wikipedia as an 'atypical microkernel', which is part microkernel, part hybrid.

http://en.wikipedia.org/wiki/Kernel_%28computer_science%29#...

Also, from what I've read some nanokernels with limited amounts of features do fine.

Projects like Gnu HURD are, in my humble opinion, destined to fail if they persist in aiming for a 'theoretically pure' implementation anyway; I believe hybrids to feature the best of both worlds. If you use services and modules, you can get performance, customisability, hotreloadability and overseeable complexity at multiple levels all at the same time. No surprise the kernels most used in practice feature either modules or services.

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

Reply Score: 1

Pixie Member since:
2005-09-30

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! ;)

Reply Score: 1

Opinionated but fair
by joecool on Sun 16th Apr 2006 17:14 UTC
joecool
Member since:
2006-02-19

I definitely like how the article does not only present positive traits of the microkernel, but also describes the corresponding negative traits. In addition, I think that's the first time I read that very interesting Linus vs. Tanenbaum thread. Great read overall.

Reply Score: 2

It's easy
by JMcCarthy on Sun 16th Apr 2006 17:15 UTC
JMcCarthy
Member since:
2005-08-12

It's easy to fall in love with the premise of microkernels when you've never actually designed&implemented one.

Reply Score: 2

v It's easy
by mOOzilla on Sun 16th Apr 2006 17:18 UTC
multiple processors
by evert on Sun 16th Apr 2006 17:29 UTC
evert
Member since:
2005-07-06

I guess a microkernel makes better use of multiple CPU's. So it should scale better.

Reply Score: 1

RE: multiple processors
by renox on Sun 16th Apr 2006 18:22 UTC in reply to "multiple processors"
renox Member since:
2005-07-06

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.

Reply Score: 2

RE[2]: multiple processors
by somebody on Sun 16th Apr 2006 18:56 UTC in reply to "RE: multiple processors"
somebody Member since:
2005-07-07

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.

Reply Score: 1

RE: multiple processors
by nick on Mon 17th Apr 2006 06:15 UTC in reply to "multiple processors"
nick Member since:
2006-04-17

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!)

Reply Score: 3

RE[2]: multiple processors
by Cloudy on Mon 17th Apr 2006 07:20 UTC in reply to "RE: multiple processors"
Cloudy Member since:
2006-02-15

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.

Reply Score: 1

RE[3]: multiple processors
by nick on Mon 17th Apr 2006 09:58 UTC in reply to "RE[2]: multiple processors"
nick Member since:
2006-04-17

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.

Reply Score: 1

walnut tree
Member since:
2005-11-15

I like the idea of an application or device that does one thing and does it well. But in the technology field, "convergence" is the name of the game. And this is partly being driven by consumers who want functionality in neat all-in-one packages rather than as separate components.

It's not always bad though. I prefer a simple mobile phone, but I can see the appeal of a phone with MP3 player and (basic) digital camera. Would you rather have one integrated device or carry three separate devices?

On paper, the microkernal design seems simple and elegant. The modular structure gives you the impression of a plug-and-play system where new functionality can be dropped in without having to re-engineer the whole OS - whether it's actually like that in real life though is another thing.

Reply Score: 1

Cloudy Member since:
2006-02-15

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.

Reply Score: 2

great article
by JrezIN on Sun 16th Apr 2006 17:36 UTC
JrezIN
Member since:
2005-06-29

Great article.

In my experience, microkernel systems have better stability and are usually faster to general-propose operations (no really talking about automation systems, like car-building Robots' operation systems, and similar situations...), like a desktop operational system. Maybe it's the kind of standard organization that the system works around; but still in the end, better systems (talking about the practical results).

Another problem these days that microkernels help with, are licensing problems. Since binary compatibility is much easier to maintain as the kernel itself doesn't change too much. So, as the system "talks" a single language, code don't need to "touch" other (license's) code and the user don't need to worry about this kind of problems, it's easier to have everything "just working"...

Reply Score: 2

Well - not everyone agrees
by ratatask on Sun 16th Apr 2006 17:55 UTC
ratatask
Member since:
2006-01-28

I suggest the OP (and others too) read
http://fred.cambridge.ma.us/c.o.r.flame/msg00025.html

Reply Score: 2

Clock in kernel
by bleurgh on Sun 16th Apr 2006 18:10 UTC
bleurgh
Member since:
2006-04-16

While the clock driver in minix is in the kernel, it doesn't not run in kernel mode. Minix has some kernel processes, called the kernel tasks which run in ring1 (kernel is ring0) and the clock is one of them. The reason, i'd assume for the clock to be in the kernel, is so that it can call enqueue and dequeue directly, which is part of the scheduling system though this could be be done equally as easily from a separate process I suppose. Actually, from just looking at the sources, the clock task interrupt is different to the interrupt handlers for the other hardware drivers. Most handlers send a HARD_INT message on every interrupt. You dont want to do this with the clock because it would cause 4 context switches each time, so the solution is to put a special clock interrupt handler in he kernel, so that HARD_INT messages are only called when the need to be, i.e. a process has used up all its time and needed to be switched out.

Reply Score: 2

RE: Clock in kernel
by smitty on Sun 16th Apr 2006 19:12 UTC in reply to "Clock in kernel"
smitty Member since:
2005-10-13

Yes, for Minix 2 anyway, the reason the clock task interrupt is handled specially is for performance reasons. By putting it in the kernel (and moving away from a pure microkernel design) you can eliminate significant delays.

Reply Score: 1

Heads should roll at NASA/ESA/BAe/Airbus
by mOOzilla on Sun 16th Apr 2006 19:41 UTC
mOOzilla
Member since:
2006-04-11

Somebody should tell NASA/ESA/BAe/Airbus et all that they got it wrong they shouldn't be using VxWorks and QNX for mission critical systems and jump to Linux. Heads should ROLL in upper management!

Reply Score: 1

Microkernels today
by mOOzilla on Sun 16th Apr 2006 19:43 UTC
mOOzilla
Member since:
2006-04-11

Examples of microkernels and operating systems based on microkernels:

* AmigaOS
* Amoeba
* Brainix
* Chorus microkernel
* Coyotos
* EROS
* K42
* LSE/OS (a nanokernel)
* KeyKOS (a nanokernel)
* The L4 microkernel family, used in TUD:OS, GNU Hurd.
* Mach, used in original GNU Hurd, NEXTSTEP, OPENSTEP, and XNU (used in Mac OS X)
* MERT
* Minix
* MorphOS
* Phoenix-RTOS
* QNX
* RadiOS
* Spring operating system
* Symbian OS
* VSTa

Reply Score: 2

More kernels
by mOOzilla on Sun 16th Apr 2006 19:48 UTC
mOOzilla
Member since:
2006-04-11

Hybrid kernel examples

* BeOS kernel
* DragonFly BSD; being the first non-Mach BSD OS to adopt a hybrid kernel architecture.
* Haiku kernel
* NetWare kernel
* ReactOS kernel
* Windows NT, Windows 2000, Windows XP and Windows Vista kernels
* XNU kernel (core of Darwin, used in Mac OS X)

Monolithic kernel examples

* Traditional UNIX kernels, such as the kernels of the BSDs
* Linux kernel
* The kernel of Solaris
* Some educational kernels, such as Agnix
* MS-DOS, Microsoft Windows 9x series (Windows 95, Windows 98 and Windows 98SE) and Windows Me.

Exokernels
http://66.249.93.104/search?q=cache:kuOFowAHxHIJ:pdos.csail.mit.edu...

Reply Score: 1

RE: More kernels
by Thom_Holwerda on Sun 16th Apr 2006 19:55 UTC in reply to "More kernels"
Thom_Holwerda Member since:
2005-06-29

mOOzilla, it's fine if you want to post stuff, but please refrain from cutting up your posts when it's not nescesary. What's even worse, your lists of kernels are copy/pasted directly from Wikipedia, while you do not give credit where credit's due.

Got it? Thanks.

Reply Score: 5

RE[2]: More kernels
by dylansmrjones on Sun 16th Apr 2006 20:07 UTC in reply to "RE: More kernels"
dylansmrjones Member since:
2005-10-02

There is no legal need for credit for a simple list like this. But it would have been ethical correct, but it does require that the edit function actually functions ;)

Reply Score: 1

RE[3]: More kernels
by Thom_Holwerda on Sun 16th Apr 2006 20:19 UTC in reply to "RE[2]: More kernels"
Thom_Holwerda Member since:
2005-06-29

There is no legal need for credit for a simple list like this.

I know (as plagiarism is nor a criminal, nor a civil offense), but it's just polite to give credit where credit's due. As now it seems as if the guy himself made this list.

But anyway, back on topic.

Reply Score: 5

Microkernels
by g2devi on Sun 16th Apr 2006 19:51 UTC
g2devi
Member since:
2005-07-09

Personally, I didn't think it was that good an article. For people interested in microkernels, this article is a far better read:

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

Basically, from what I've read, most of Linus' original criticisms of microkernels were correct and it wasn't until the mid 1990s that academics realized this and started from scratch with the bare bones L3 microkernel and then enhanced L4. From what I've read, L4 takes care of most of the criticism, although there is still a bit of a performance hit (though nowhere near as bad as Mach). The key thing of L4 is that it tries to focus on things that require ring0 privilege and leaves everything else to the OS. In essense, it's not all that different from Xen (although they may differ on some details). Given that VMWare and Xen are trying to come up with an API for paravirtualization ( http://osnews.com/comment.php?news_id=14334 ), I wouldn't be at all surprised if the changes are compatible with the L4 design.

Reply Score: 2

RE: Microkernels
by Cloudy on Sun 16th Apr 2006 21:44 UTC in reply to "Microkernels"
Cloudy Member since:
2006-02-15

Welcome to the late 1960s. L4 is striving mightly to be VM/370 all over again.

Reply Score: 1

v RE: More kernels
by mOOzilla on Sun 16th Apr 2006 19:57 UTC
muK vs exokernel then?
by John Nilsson on Sun 16th Apr 2006 21:54 UTC
John Nilsson
Member since:
2005-07-06

http://en.wikipedia.org/wiki/Exokernel links to this paper: http://pdos.csail.mit.edu/papers/hotos-jeremiad.ps (Dawson R. Engler & M. Frans Kaashoek, Exterminate All Operating System Abstractions) which I found really interesting.

Anyone care to argue against it? Why is muKernels better than exokernels f.ex.

Reply Score: 1

RE: muK vs exokernel then?
by Cloudy on Sun 16th Apr 2006 22:10 UTC in reply to "muK vs exokernel then?"
Cloudy Member since:
2006-02-15

I won't argume for muK because it's an implementation technique not an architectural solution, but it's pretty easy to argue against their basic thesis by observing that his paper is entirely devoid of a discussion of resource sharing.

Engler and Kasshoek completely missed, from the early history of OS design, *why* we put abstractions into operating systems: to share resources.

Throwing away OS abstractions is throwing out the baby with the bathwater. Using microkernels is demanding that all babies be small enough to bathe in a saucepan.

The trick (and it is a *hard* trick) to OS design is putting the right abstractions in place and then implementing them. Abstraction comes first, implementation comes second, iterate until satisfied.

Dennis Ritchie was very good at that. Unix has survived for as long as it has as a usable OS not because of its implementation technology but because of its original set of abstractions.

He seems to have been the last one.

Reply Score: 3

Exokernels
by nicolai on Sun 16th Apr 2006 22:06 UTC
nicolai
Member since:
2006-04-16

The concept "exokernel" can be summed up as: The kernel only performs resource allocations, the abstraction from the hardware is pushed down into a userspace library as far as possible.

This concept is completely orthogonal to the muK vs. monolithic question. You could have exokernel micro kernels and exokernel monolithic kernel.

In fact, exokernel design is used in Linux - it's how the open source 3D drivers work. The DRI people don't call it an exokernel architecture, but that doesn't change the fact that it largely is one.

Of course, it's not "pure" in the sense that the userspace driver cannot write directly into the graphics card's command buffer, but that can't be avoided for security reasons. The exokernel approach is rather limited in that way as long as you can't trust the application.

Reply Score: 2

RE: Exokernels
by Ronald Vos on Mon 17th Apr 2006 00:32 UTC in reply to "Exokernels"
Ronald Vos Member since:
2005-07-06

The concept "exokernel" can be summed up as: The kernel only performs resource allocations, the abstraction from the hardware is pushed down into a userspace library as far as possible.

This concept is completely orthogonal to the muK vs. monolithic question. You could have exokernel micro kernels and exokernel monolithic kernel.

In fact, exokernel design is used in Linux - it's how the open source 3D drivers work. The DRI people don't call it an exokernel architecture, but that doesn't change the fact that it largely is one.


Linux is all about hardware abstraction layers. In fact, it's layered-ness is what gives it it's portability. The open source 3D-drivers are an abstraction layer to other software.

Exokernels are all about removing the abstraction layers, by letting software directly interface with the hardware. Kinda like in the times of bad old DOS, only supported by libraries so that programmers don't have to manually program the interfaces to the hardware.

http://pdos.csail.mit.edu/exo/

Of course, it's not "pure" in the sense that the userspace driver cannot write directly into the graphics card's command buffer, but that can't be avoided for security reasons. The exokernel approach is rather limited in that way as long as you can't trust the application.

I don't believe it will work with the traditional UNIX security model. A capability-based security model like implemented in EROS however could work if done properly.

Reply Score: 1

RE[2]: Exokernels
by Cloudy on Mon 17th Apr 2006 01:25 UTC in reply to "RE: Exokernels"
Cloudy Member since:
2006-02-15

I dunno what Linux is "all about", but it ain't hardware abstraction. And the portability comes from a lot of people trying to force the x86 hardware model onto a lot of other architectures, not from any decent abstraction layer.

whether you can make 'user space' drivers work or not has nothing to do with the security model of the OS and everything to do with the virtual memory and i/o model of the underlaying hardware. More than anything else it has to do with how those things interact in a context switch.

There *are* hardware models where you can't do user space drivers for the simple reason that hardware i/o is priviliged so all i/o processing has to be done in 'ring 0'.

Then there are hardware models like the x86 that screw up the relationship between memory addressability and memory accessability making it difficult to switch efficiently.

Occassionally an architecture comes along like the original machines that Multics was designed for or like the HP Prism (PA-RISC) architecture that get everything right wrt to i/o processing, privilige, and addressability. On those you can have a lot of fun with user space "kernel" features.

(Which reminds me, the other Linux (in the sense that Linus uses the name) is not, is an operating system. It's a massive kernel and a set of facilities.

I guess there's some abstraction buried in the ad-hoc crap somewhere, but if it didn't come from Unix, I sure haven't been able to find it.

Reply Score: 3

Linux hardware abstraction (was RE: Exokernels)
by nick on Mon 17th Apr 2006 05:53 UTC in reply to "RE[2]: Exokernels"
nick Member since:
2006-04-17

I dunno what Linux is "all about", but it ain't hardware abstraction. And the portability comes from a lot of people trying to force the x86 hardware model onto a lot of other architectures, not from any decent abstraction layer.

Excuse me, Cloudy, I'd like some clarification on this
comment please, because it bugs me when I see it
without anything to back it up with. I just registered
now so I could ask you.

I don't know when you last looked at the Linux kernel
source code, but Linux 2.6 doesn't appear to do
anything like "force the x86 hardware model" onto other
architectures.

As you might know, Linux 2.6 is the most ported OS in
the world (in terms of CPU ISAs, not "platforms" that
NetBSD counts). It runs on architectures without MMUs,
without pagetables, systems with 1024 CPUs and 16TB+ of
RAM. Its i386 (nor the x64) architecture port can't do
any of these things.

How successful are these non-i386 ports?

The SPARC Niagara is a very different architecture
from i386, and yet Linux on the Niagara is nearly 50%
faster than Solaris 10, and 10% faster than Solaris
Express (OSes which are explicitly designed to run on
SPARCs).
http://www.stdlib.net/~colmmacc/category/niagara/

On SPECjbb, Linux is within 90% of AIX on 32 core
POWER5 systems (although not exactly the same user
software and that was a couple of years ago).

Linux is much, much faster than OSX on PowerPC hardware
(G5 systems). No link, but you shouldn't have trouble
finding results on google.

On Itanium systems it holds its own against MS Windows
and HP-UX, although it is hard to find benchmarks on
identical systems (tpcc and tpch give some ideas).

Reply Score: 2

Cloudy Member since:
2006-02-15

Last time I looked at Linux kernel code: about half an hour ago. 2.6.17-git. ARM OMAP730, to be precise, as I've been working on it again.

For years, at various times, I was responsible for Linux kernels on various embedded platforms.

It's not the most ported OS in the world in terms of ISAs. Unix (meaning the Bell Labs RE code base) has been ported, in one form or another to not only numerically more ISAs, but dramatically different ISAs than Linux has been ported to.

None of your comments address the point I raised, by the way. Linux has been ported to a wide range of architetures. Not as wide a range as we had ported Unix to back in the 80s, but then, the range of architectures around now isn't as wide as it was then, by a large amount.

But the way it was ported was not through implementing a Linux device abstraction layer on top of the hardware of various systems as has been claimed, for the simple reason that there is *no* Linux device abstraction layer.

Linux, sort of, has a Unix device abstraction model, with various warts on the side, but that's only in the interface that's visible across the user/kernel boundary.

Internally, it doesn't have device abstractions. (Do I have to dig up the URL of Linus' famous quote about interfaces?)

Not only does it not have device abstractions, but the device layer changes. Frequently. Drivers for 2.6.8 won't work on 2.6.10. Similarly 2.6.10 drivers will break on 2.6.12. Interfaces change all the time. Device models vary at the whim of developers.

Take, for instance, the famous, on-going battle over the SCSI abstration layer(s) and how they should be implemented.

Or, to pick another random example, the five different device naming schemes floating around the kernel, in various states of repair, with various levels of support.

It's a fun system. I enjoy recapturing the 80s. But it ain't one based on any abstraction layers.

Reply Score: 3

nick Member since:
2006-04-17

Last time I looked at Linux kernel code: about half an hour ago. 2.6.17-git. ARM OMAP730, to be precise, as I've been working on it again.

OK that's great, but it doesn't explain why you didn't
answer my fundamental question: how does Linux force
the "x86 model" on other architectures?!?

It's not the most ported OS in the world in terms of ISAs. Unix (meaning the Bell Labs RE code base) has been ported, in one form or another to not only numerically more ISAs, but dramatically different ISAs than Linux has been ported to.

Portability -- I'm talking about being compiled from
the same source base. Obviously pretty much any bit of
software can be "ported" to another system, but it
takes more finesse to support both systems at the same
time.

Maybe I shouldn't say most ported, but it is the most
portable operating system. Whatever. Semantics. I'm
sure you understand what I mean.

But the way it was ported was not through implementing a Linux device abstraction layer on top of the hardware of various systems as has been claimed, for the simple reason that there is *no* Linux device abstraction layer.

Sorry, there are plenty. There is a pci layer, which is
basically evolving into a generic bus layer. There is a
network device layer, a block device layer, there is a
MMU / virtual memory abstraction, a CPU context
abstraction, etc etc.

Not only does it not have device abstractions, but the device layer changes. Frequently. Drivers for 2.6.8 won't work on 2.6.10. Similarly 2.6.10 drivers will break on 2.6.12. Interfaces change all the time. Device models vary at the whim of developers.

Of course, this is one of the reasons why it is a good
system IMO.

Take, for instance, the famous, on-going battle over the SCSI abstration layer(s) and how they should be implemented.

Err, how should I "take" that? The fact that there is a
battle over the abstraction layer should suggest to you
that there is actually an abstraction layer in place.

Or, to pick another random example, the five different device naming schemes floating around the kernel, in various states of repair, with various levels of support.

Huh? There is and always has been the (major,minor)
system and the network interface system for char,
block, and network drivers. And that's fully supported.

There is the now obsolete devfs which was mostly
replaced by sysfs, to represent device topology. Sysfs
doesn't impose a device naming scheme though.

So at most there are 2 device naming schemes in the
kernel, major,minor and devfs. 3 if you count sysfs,
2 of which are fully supported.

It's a fun system. I enjoy recapturing the 80s. But
it ain't one based on any abstraction layers.


Well it has many abstraction layers so you're just
plain wrong. I don't know what you think an abstraction
layer is though... maybe you should put down the crack
pipe before posting again.

Reply Score: 1

Cloudy Member since:
2006-02-15

With respect to the question about the x86 model, you answer your own question. There is, as you say, a "PCI layer". Not, you will note, an abstraction of control busses, but a layer specific to a particular kind of bus.

This, I think, is the point you're missing. Having layers is not the same thing as having abstraction layers. The PCI layer is very much a PCI layer, and not a bus layer. There is no bus abstraction layer that the PCI layer is derived from. So for SCSI, there is the SCSI layer, which is not at all similar to the PCI layer, even when SCSI is similar to PCI.

Second, The RE code base was a single code base, and ported to a far wider range of ISAs than Linux has ever been ported to. How many bit-addressable machines does Linux run on? How many 48 bit-machines? How many machines on which char is not 8 bits?

Computer architectures are much more similar now than they were in the 80s, and even by the 80s they were starting to homogonize.

Discovering the remaining device name spaces is left as an exercise to the reader: (hint, you missed proc) Oh, by the way, devfs may be obsolete, but it's still in the tree, and still widely used.

Speaking of which, you are incorrect in your claim that Linux is ported from a single code base. The last time I counted, there were something like a dozen interrelated code bases that I was interested in. You can't, for example, boot the TS7200 I'm working with right now, from any of the kernel.org trees, not even the tip of git.

Linux, which is just a kernel and not an OS, has many layers. They are not, however, *abstraction* layers.

Reply Score: 2

nick Member since:
2006-04-17

With respect to the question about the x86 model, you answer your own question. There is, as you say, a "PCI layer". Not, you will note, an abstraction of control busses, but a layer specific to a particular kind of bus.

Well, when I look around I see PCI busses in your
beloved PARISC to IA64 Altixes, Alphas, POWER servers,
even mainframes. So not only have I not answered my
own question, you still haven't answered it either.
I'm waiting, please.

This, I think, is the point you're missing. Having layers is not the same thing as having abstraction layers. The PCI layer is very much a PCI layer, and not a bus layer. There is no bus abstraction layer that the PCI layer is derived from. So for SCSI, there is the SCSI layer, which is not at all similar to the PCI layer, even when SCSI is similar to PCI.

Umm, no. The pci layer does a lot of work at
abstracting PCI bus implementation details. It
definitely abstracts PCI programming. The pci API
is actually mostly good enough to abstract other
busses as well.

As for the SCSI comment... no comment.

Second, The RE code base was a single code base, and ported to a far wider range of ISAs than Linux has ever been ported to. How many bit-addressable machines does Linux run on? How many 48 bit-machines? How many machines on which char is not 8 bits?

I really don't care. I didn't say anything about that.
I didn't say a wider range of ISAs (whatever that might
mean).

Linux runs on the most architectures.

Discovering the remaining device name spaces is left as an exercise to the reader: (hint, you missed proc) Oh, by the way, devfs may be obsolete, but it's still in the tree, and still widely used.

I didn't miss proc (hint, it isn't a device naming
scheme).

Speaking of which, you are incorrect in your claim that Linux is ported from a single code base. The last time I counted, there were something like a dozen interrelated code bases that I was interested in. You can't, for example, boot the TS7200 I'm working with right now, from any of the kernel.org trees, not even the tip of git.

I'm not talking about any of those branches. I'm
talking about Linus' tree. If you count branches and
forks, then you end up having even more.

Linux, which is just a kernel and not an OS, has many layers. They are not, however, *abstraction* layers.

Well you are wrong.

Reply Score: 1

Gunderwo Member since:
2006-01-03

"Well it has many abstraction layers so you're just
plain wrong. I don't know what you think an abstraction
layer is though... maybe you should put down the crack
pipe before posting again."

Just because he didn't explain his statement as clearly as you may have liked is no reason for a personal attack of this nature. I've read all of Cloudy's posts and it seems he knows about what he's speaking. It's comments like this that cause people to stop posting and I commend Cloudy for ignoring your attack and thoughtfully answering your questions and comments. By the way I found the majority of your post to be well thought out and helped to further the discussion nicely until your final comment.

So in the future it would be appreciated if you could keep your comments on topic and not resort to attacking one of the few people here who seems to know what he's talking about. I have no problem with you disagreeing with his assertions, but please try and adress your comments in a more respectful manner.

Greg ;)

Reply Score: 2

nick Member since:
2006-04-17

So in the future it would be appreciated if you could keep your comments on topic and not resort to attacking one of the few people here who seems to know what he's talking about. I have no problem with you disagreeing with his assertions, but please try and adress your comments in a more respectful manner.

I happen to be not entirely clueless either. So I
started by politely and clearly asking him to back
up his claim that:

"portability comes from a lot of people trying to force
the x86 hardware model onto a lot of other architectures"

And as you can see, I've asked him about 10 times now
and he cannot answer. I wouldn't mind this so much if
he'd just admit he was wrong and withdraw that offensive
and baseless statement, but no he keeps trying to
attack me and make up straw men to distract from the
main point.

Asking someone to put down the crack pipe isn't a
personal attack. It is just a phrase used to say that
you think the poster is completely wrong.

And he is, I can provide any number counter-examples of
abstraction layers in Linux as you'd like (problem with
Cloudy is that he just denies they are abstraction
layers and thinks he's won the argument!!).

Here's one: the architecture specific CPU context is
abstracted away from generic code (like the scheduler)
with architecture-private structures attached to
threads, and with the "switch_to()" function to switch
between contexts. See around line 1652 in kernel/sched.c

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.gi...

to see how the generic scheduler performs a full CPU
context switch with about a dozen lines of code. And
nothing x86 specific about that at all.

If you don't think that's an abstraction... you need to
put down the crack pipe ;)

Reply Score: 1

RE[2]: Exokernels
by jonsmirl on Mon 17th Apr 2006 01:27 UTC in reply to "RE: Exokernels"
jonsmirl Member since:
2005-07-06

The DRM drivers are not an abstraction layer. The interface from each driver is different depending on the chip family. So I believe DRM/mesa does qualify as an exokernel design.

The layers look like this. libGL, common API for all to use. DRI, user space code that is specific to the chip family being supported. DRI and libGL are usually linked into the same shared object since most people only have one video card. This does not have to be done and it wasn't done a few years ago.

Finally there is DRM which is the kernel space driver. There are about 30 common DRM ioctls which control standard things like file handles and enabling interrupts. But you can't draw anything with the common ioctls. Next there are from 10 to 50 chip specific ioctls which control the meat of the hardware.

libGL (mesa) implements all drawing functions in software. The DRI libraries replace libGL functions with hardware accelerated ones if the hardware is capable. If a function can't be accelerated it falls back to the software implementation since it hasn't been replaced.

The ATI radeon family is a special case. There is one radeon DRM module since the core of all the radeon chips is very similar. But there are three DRI implementations R100, R200 and R300. The DRM driver sets up the DMA queue, but the commands that user space writes to the queues is different in each DRI driver.

Security is a problem. The DRM drivers need to scan the DMA commands to make sure no one is using the DMA hardware to peek at memory not owned by the calling process. Remember that DMA works on physical memory pages and can scan any of them. If you can get to arbitrary memory you can always gain root priv. To address this problem AMD is doing IOMMUs. Hypervisors hit this problem too.

Reply Score: 3

Unix is abstract?
by mOOzilla on Sun 16th Apr 2006 22:56 UTC
mOOzilla
Member since:
2006-04-11

Thats a good one, everythings a file. Thats VERY abstract.

Reply Score: 1

RE: Unix is abstract?
by Cloudy on Sun 16th Apr 2006 23:12 UTC in reply to "Unix is abstract?"
Cloudy Member since:
2006-02-15

"Everything's a file" is more Pike than Ritchie. Ritchie knew when to stop ;)

Ritchie's big contribution to modularity was pipelines. There's a need to get back to that sort of decoupling.

Here's a minimum set of abstractions:

byte-sequence (memory abstraction)
byte-source/sink (i/o abstraction)
thread (control flow abstraction)
time (because otherwise nothing happens)
uid (user abstraction)
permission (security abstraction, a mapping of booleans on the 4-plex {uid, time, object, operations})
process (a collection consisting of a uid, one or more threads, and one or more permissions)

All OS-es must provide at least this set of abstractions and one or more name spaces for manipulating them.

Ritchie's brilliance included designing a compact set of orthogonal abstractions and a very small number of name spaces.

You'll find that most of the mistakes in Unix consist of poor choices of or inappropriate exposure of name spaces. The most obivous of which is the exposure of PID.

The art of OS design is filling in the collection of operations allowed on the abstractions.

Reply Score: 5

um
by Unbeliever on Mon 17th Apr 2006 01:05 UTC
Unbeliever
Member since:
2005-07-09

You never told us why *you* like them. You told us what they are (in very... general terms, to say the least), and you told us what they do, but none of the things you said support your reasons for liking microkernels.

Either that, or there's something to this poorly-researched article that I'm not quite grasping.

Perhaps.

Reply Score: 2

"Kernel"
by TADavis on Mon 17th Apr 2006 01:17 UTC
TADavis
Member since:
2006-03-13

I'm shopping around for a name besides "kernel" for my operating system's lower memory module. I don't use priviledge features of the CPU, so "Kerenl" leads to confusion. The boot loader which does a BIOS call can only access the bottom meg of RAM initially, so my "Kernel" has a size limit. It must accomplish one thing--enable full memory and load the rest. It needs support for disk access and knowledge of file systems. I don't want redundency so this low memory "kernel" has the real file access routines. Soon, it'll need USB support for flash booting.

This is an operating system for home hobbiests who prefer total access to their machine over security. It's programming heaven when you're free to turn-off interrupts or whatever as you see fit. Nothing wrong with it if you know what you're doing.

Anyway, there are only two binary modules--the "kernel" and the compiler. Everything else is compiled each time you boot--still boots in like 3 seconds. The compiler is blazing fast. I thought some people might be confused because the "kernel" binary is so small, yet there is so much source code. "Microkernel" might be how someone described it but it's not very accurate.

http://www.justrighteous.org

I recently changed the name of a special task which is the parent of all other tasks from "ROOT" to "ADAM" because there was confusion. "ROOT" scared people, I heard, which is pretty funny since everything is root!!

Reply Score: 1

RE: "Kernel"
by siride on Mon 17th Apr 2006 01:27 UTC in reply to ""Kernel""
siride Member since:
2006-01-02

Somebody already made an OS like that...it's called DOS.

Reply Score: 1

RE[2]: "Kernel"
by TADavis on Mon 17th Apr 2006 01:33 UTC in reply to "RE: "Kernel""
TADavis Member since:
2006-03-13

My operating system is for programmers who know what they're doing and don't want to be annoyed by road blocks to accessing their own machine. When will people see that a home operating system doesn't have to be the same as a server or multiuser operating system. It's criminal how many man hours have been wasted fiddling with file permissions and stuff when there's no need.

Reply Score: 0

RE[3]: "Kernel"
by Cloudy on Mon 17th Apr 2006 01:50 UTC in reply to "RE[2]: "Kernel""
Cloudy Member since:
2006-02-15

I had this very debate with RMS about 20 years ago. It's interesting how it keeps resurfacing.

The freedom to do whatever you want to your system is very appealing.

But there are compelling reasons to have programs broken up into separate bits and use the virtual memory hardware to protect the bits from each other: we *all* make mistakes.

Believe me, the time wasted tracking down stray pointer references and other similar bugs that cause subsystem A to corrupt subsystem B is far more criminal than the time wasted fiddling protection states.

Reply Score: 3

RE[3]: "Kernel"
by siride on Mon 17th Apr 2006 04:08 UTC in reply to "RE[2]: "Kernel""
siride Member since:
2006-01-02

I'm sure the people who suffer from malware and spyware would love to hear how having even less security and protection would solve their woes.

Reply Score: 2

RE: "Kernel"
by Cloudy on Mon 17th Apr 2006 01:31 UTC in reply to ""Kernel""
Cloudy Member since:
2006-02-15

After a *very* quick look at your web site, I'd say you've got a boot loader on your hands and that you're implementing the Nth in an infinite series of single-addres-space single-protection-domain multi-tasking DOS replacements.

But all that matters is that you're having fun with it. I encourage you to keep at it.

Reply Score: 2

ma_d
Member since:
2005-06-29

Thom makes a great point about Microkernels, the part that is absolutely important to the security of your system (a processor and memory) is very small and thus can be bug free (or amazingly close to it).

A kernel like Linux has millions of lines of code which can all do anything they like.

So here-in lies the crux: Are drivers which can't harm your system better than ones that can?

Well, the question that comes to mind is: Does your application need to driver to be as stable as the OS?

I'm willing to bet that the majority of your devices you consider their working to be crucial. Of course, you need your network card working, and disk drives, and your video card (well, maybe it can glitch but all out failures would be a nightmare to productivity on a desktop).

So, the system can stay up and not damage things when your video driver does something stupid. Great. Can you afford that occurance? No. So what's the point? You still have to write the same quality of video driver?

The largest benefactor I see in this situation is actually developers: They have a nice testing platform that slaps them quick when they make a mistake.


My design hat loves the idea of a microkernel. It's such a nice thought to look at. But my design hat also tells me it just might be a giant waste of time, computer and human alike.
It's probable that a mix is the best solution. I'm no kernel expert, but it seems to be that things like drivers just have to be as close to perfect as possible, but things like packet routing might benefit from protection.

Reply Score: 2

nick Member since:
2006-04-17

How can microkernel drivers "not harm you system"?!?

A buggy disk driver can hose your disks. A buggy
filesystem driver can corrupt your filesystem. A
buggy memory manager can corrupt memory. A buggy
network driver can corrupt network traffic.

Aside from corruption, their failure obviously will
result in the denial of usually critical system
resources like memory, filesystem, or IO device access.

So I don't see how microkernel proponents can be
lulled into this false sense of security.

Reply Score: 3

AndyZ Member since:
2005-07-05

Corrupting a filesystem is one point of failure, but a failed "server" (as in driver) can be restarted. If its not possible for the microkernel to restart ie the network or filesystem driver again, then how could they be started in the first place(at boottime)?

AndyZ

Reply Score: 1

nick Member since:
2006-04-17

I didn't say it wasn't possible. Neither would it be
impossible to do a similar reinitialisation of some
subsystem or driver in a monolithic kernel.

I don't try to claim there are no advantages of a
microkernel -- obviouly there are some otherwise even
their most stubborn supporters would give up on the
idea in the face of all their disadvantages.

But this (immunity of the system / data from bugs) is
not one of them.

Reply Score: 1

Brendan Member since:
2005-11-16

Consider a dodgy driver or service that occasionally writes to random addresses.

In a traditional monolithic system, the driver/service would be implemented as part of the kernel and can trash anything that's running on the computer - nothing will stop if from continuing to trash things, and nothing will help to detect which driver or service is faulty.

On a basic micro-kernel the driver/service can't effect anything else in the system, and sooner or later it'd generate a page fault and be terminated. This makes it much easier to find which driver or piece of software was faulty, and means that damage is limited.

In this case, you're still partially screwed because everything that was relying on that driver or service will have problems when that driver/service is terminated. This isn't always a problem though (it depends on what died) - for example, if the driver for the sound card dies then no-one will care much. If the video driver dies then the local user might get annoyed, but you could still login via. network and things like databases and web servers won't be effected.

The more advanced a micro-kernel is the more systems it will have in place to handle failures.

For example, if the video driver dies the OS might tell the GUI about it, try to download/install an updated driver, then restart the video driver and eventually tell the GUI that the video is back up and running. The user might lose video for 3 seconds or something but they can still keep working afterwards (and there'd hopefully be an explanation in the system logs for the system administrators to worry about).

Another way would be to use "redundancy". For example, have one swap partition on "/dev/hda3" and another on "/dev/hdc3" with 2 seperate disk drivers. Writes go to both disk drivers, but reads come from the least loaded disk driver. In this case the system would be able to handle the failure of one swap partition or disk driver (but not both). With fast enough networking, maybe keeping a redundant copy of swap space on another computer is an option..

The point is that for monolithic kernels you don't have these options - if anything in kernel space dies you have to assume that everything in kernel space has become unreliable, and rebooting is the only reliable option (if the code to do a kernel panic and reboot hasn't been trashed too).

Most developers of monolithc systems will say that it's easier to make their drivers and services bug free than it is to implement systems to recover from failures. They may be right, but it might be "wishful thinking" too...

Reply Score: 2

nick Member since:
2006-04-17

What if the soundcard driver gets corrupted and starts
DMA to a random page of memory that was actually some
filesystem's pagecache[*]?

What if a driver goes haywire and starts sending the
wrong IPC messages down the pipe?

Another way would be to use "redundancy". For example, have one swap partition on "/dev/hda3" and another on "/dev/hdc3" with 2 seperate disk drivers. Writes go to both disk drivers, but reads come from the least loaded disk driver. In this case the system would be able to handle the failure of one swap partition or disk driver (but not both). With fast enough networking, maybe keeping a redundant copy of swap space on another computer is an option..

I don't think so. You have to have at least 3 devices
and 3 different drivers and perform checksumming across
all data that comes out of them if you really want to
be able to discard invalid results from a single
driver. Or you could possibly store checksums on disk,
but if you don't trust a single driver...

I think in general it would be far better to go with
RAID, or a redundant cluster wouldn't it?

The point is that for monolithic kernels you don't have these options - if anything in kernel space dies you have to assume that everything in kernel space has become unreliable, and rebooting is the only reliable option (if the code to do a kernel panic and reboot hasn't been trashed too).

A microkernel can fail too, end of story. If you need
really high availability, you need failover clusters.

And within a single machine, I happen to think
hypervisor/exokernel + many monolithic kernels is a
much nicer solution than a microkernel.

[*] Perhaps you might have DMA services in the kernel
and verify all DMA requests are going to/from
driver-local pages, yet more overhead... does any
microkernel do this?

Reply Score: 2

Brendan Member since:
2005-11-16

Hi,

What if the soundcard driver gets corrupted and starts
DMA to a random page of memory that was actually some
filesystem's pagecache[*]?


Then you're screwed regardless of what you do. PCI bus mastering is the only thing a micro-kernel can't protect against (I've never found anything that can protected against it at least, but AMD's virtualization hardware might help - I haven't looked into it so I'm not sure). For the ISA DMA controllers it's easy to force drivers to use a kernel API where decent checking can be done (if you haven't guessed, I'm more for slightly largish micro-kernels than for minimalistic nano-kernels).

What if a driver goes haywire and starts sending the wrong IPC messages down the pipe?

It's standard programming practive (or at least it should be) to always check input parameters before doing anything, especially if these input parameters come from elsewhere (e.g. function parameters, command line arguments, message contents, environment variables, etc). All "message receivers" should also be able to check who sent the message. If the message still passes all of this, then the receiver might do something that isn't desired, but it's very unlikely this would lead to major problems.

I don't think so. You have to have at least 3 devices
and 3 different drivers and perform checksumming across
all data that comes out of them if you really want to
be able to discard invalid results from a single
driver. Or you could possibly store checksums on disk,
but if you don't trust a single driver...


You are right - 2 redundant drivers/services can recover from detectable failures, but 3 are required to detect some types of failure. For a failure like completely crashing (page fault, general protection fault, etc) 2 drivers/services are enough, but for checksumming you need at least 3.

I think in general it would be far better to go with
RAID, or a redundant cluster wouldn't it?


Regardless of how good it is, hardware RAID has at least 2 single points of failure (the device driver and the controller). Having entire redundant computers (or a redundant cluster) is an option for all types of kernels (but it's not so cheap).

A microkernel can fail too, end of story. If you need
really high availability, you need failover clusters.


Of course - but it's easier to find/fix bugs in something small, that isn't cluttered full of every device driver imaginable.

And within a single machine, I happen to think
hypervisor/exokernel + many monolithic kernels is a
much nicer solution than a microkernel.


You mean like running 8 versions of Vista on the same machine so that you can edit text files without worrying about messing up your web server? Hardware manufacturers would love the idea (just think of the extra sales)!

Reply Score: 1

Cloudy Member since:
2006-02-15

The point is that for monolithic kernels you don't have these options - if anything in kernel space dies you have to assume that everything in kernel space has become unreliable, and rebooting is the only reliable option (if the code to do a kernel panic and reboot hasn't been trashed too).

This is true in most implementations, but it is a feature of the implementation rather than a necessity of the system. It is, given reasonable VM design, possible to make the user/supervisor transition distinct from the addressability distinction.

You can have a 'monolithic' kernel in the user/supervisor sense -- meaning that the whole thing is compiled as a unit and all runs in supervisor mode -- without having to have one in the memory addressability sense -- meaning that various subsystems can only access what they're allowed access to.

Reply Score: 2

Brendan Member since:
2005-11-16

This is true in most implementations, but it is a feature of the implementation rather than a necessity of the system. It is, given reasonable VM design, possible to make the user/supervisor transition distinct from the addressability distinction.

Unfortunately, all VM implementations are restricted by what the hardware provides. For (32 bit) 80x86 this means paging and segmentation. Therefore, to seperate access from addressability you'd either need to modify the permission bits in the paging structures during each transition (very time consuming) or use segmentation.

While segmentation could help, it isn't a complete solution - it can provide a distinction between 4 privilege levels, but code at higher privilege levels can trash anything at lower privilege levels (e.g. drivers could trash user space and each other, but not the kernel itself). Of course for portability (even to 64 bit 80x86) you can't rely on segmentation anyway.

I guess it would be possible to design hardware to overcome this problem, but IMHO it'd make more sense to make context switching faster. For e.g. have "CR3 tagged" TLB entries so that address space switches aren't so expensive, which would benefit all kernels to varying degrees and could be added to 80x86 without requiring changes to any existing software.

Reply Score: 1

ma_d Member since:
2005-06-29

I did define system as memory+cpu didn't I?

Reply Score: 1

Why should there be kernels anyway?
by axilmar on Mon 17th Apr 2006 13:56 UTC
axilmar
Member since:
2006-03-20

I think that the concept of 'kernel' is a mistake and it exists only because CPUs are not sophisticated enough to provide proper isolation between software components. The discussion between monolithic kernels/modular kernels/microkernels would not take place if CPUs allowed us to provide only the necessary connections between components.

The reason microkernels exist is because it makes it easier to construct an O/S from components that are physically isolated and can not affect each other. But the physical barriers between processes make microkernels not as fast as 'monolithic' kernels.

I think the solution lies in between: CPUs should provide ways of linking components together without allowing undesirable interactions. For example, a graphics driver component should only be able to access the video card and the application's memory and not all the hardware and memory; a hard disk I/O component should only be able to access the hardware I/O subsystem and app's memory buffers and not anything else etc.

I think the above could be achieved with a solution called 'memory map'. Just like a process has a page map, a software component should also have a memory map, i.e. a range of addresses that it is allowed to access. Inter-component communication shall be possible by mapping one part of a component to another component's memory map. By calling a routine of another component, the current memory map would be replaced with the memory map of the current component; upon return, the previous memory map would be restored. The advantage of this solution would be tremendous flexibility in componentization of an O/S:

1) no performance costs like in a microkernel.
2) no safety/security problems like in a non-microkernel.

Memory maps would make traditional kernels reduntant: all that would be needed is a small program that would coordinate memory maps. The rest of the functionality would be placed in components, the memory maps of which are built by the small program mentioned above.

Reply Score: 1

Brendan Member since:
2005-11-16

I think the above could be achieved with a solution called 'memory map'. Just like a process has a page map, a software component should also have a memory map, i.e. a range of addresses that it is allowed to access.

Accessing RAM is slow, but accessing several levels of the paging structures and severel levels of "memory map" structures and the final physical RAM location (every time the CPU accesses RAM) would be unbearable. That's why CPUs cache the paging structures (TLB), and that's why they'd need to cache the "memory map structures". If you're going to change the "memory map" structures every time the CPU changes between software components then you'll lose the benefits of this caching and end up with "memory map structure cache" misses.

You might aswell just change the paging structures instead (which is what micro-kernels do)...

Reply Score: 1

Cloudy Member since:
2006-02-15

The trick is to use systems on which the transition between protection domains is assisted by the VM hardware rather than hindered. The PA-RISC VM model, for example, makes transitions between memory protection domains very fast, nearly as fast as procedure calls that don't transition.

This is what hardware designers and OS designers keep missing. The VM system should make accessability and addressability of memory distinct so as implementation of protection domains in this way is cheap.

We at HP tried to convince Intel to do this in Itanium, but I didn't stick around long enough to see if it made it.

Reply Score: 2

Big problems with microkernels
by abraxas on Mon 17th Apr 2006 15:07 UTC
abraxas
Member since:
2005-07-07

Why was there no mention of the biggest problems microkernels face, namely message passing synchronicity? The inherent complexity of a microkernel still outweighs the benefits of one, for most systems. This is mostly due to issues concerning message passing and the manner in which messages are given priority.

Reply Score: 1

RE: Big problems with microkernels
by Cloudy on Mon 17th Apr 2006 20:20 UTC in reply to "Big problems with microkernels"
Cloudy Member since:
2006-02-15

You can easily solve the synchronicity problem by using queues and using call backs.

The major problem that message passing has isn't synchronicity, it's overhead. Extra context switches, and the cost of marshalling are significant, even in highly optimized message passing systems.

Reply Score: 2

abraxas Member since:
2005-07-07

I think you're missing my point. The overhead of a microkernel is caused mostly by mechanisms that control synchronicity. It's not necessarily that overhead is the specific problem, it is that it seems the only way to solve the synchronicity problem is to introduce a lot of context switching which means a lot of overhead. Overhead is never a problem in itself, it is just a symptom of a problem.

Reply Score: 1

People attacking microkernels
by proforma on Tue 18th Apr 2006 05:49 UTC
proforma
Member since:
2005-08-27

Because Linux does not have a microkernel a lot of people are attacking the idea. Because of course if Linux doesn't have it, it must not be good to begin with.

Why not be better than that?

This is the reason I really don't care about this website/forum so much. It's like the loser slashdot crowd bored to death so they have to come here to put everything else in the universe down but Linux.

Honestly, I don't care much for linux, but I care even less for their hippy, everything should be free fanboys.

Reply Score: 1

Thom != kernel programmer
by j-s-h on Tue 18th Apr 2006 17:44 UTC
j-s-h
Member since:
2005-07-08

Thom Thom Thom, how many microkernels did you program today?

Reply Score: 1