Slashdot Mirror
First Program Executed on L4 Port of GNU/HURD
wikinerd writes "The GNU Project was working on a new OS kernel called HURD from 1990, using the GNU Mach microkernel. However, when HURD-Mach was able to run a GUI and a browser, the developers decided to start from scratch and port the project to the high-performance L4 microkernel. As a result development was slowed by years, but now HURD developer Marcus Brinkmann made a historic step and finished the process initialization code, which enabled him to execute the first software on HURD-L4. He says: 'We can now easily explore and develop the system in any way we want. The dinner is prepared!'"
The L4 kernel is built around the x86 (really all modern CPUs) concept of processor "rings". The kernel itself resides at ring0, drivers at ring1, and so on.
The big thing is that in ring0, no one can interrupt you. So a kernel can run many cycles uninterrupted by applications. Mainly, this is used for scheduling and precise timing.
What L4 seeks to do is bring all levels of processing out to ring4. By doing this, they minimize the amount of code that cannot be preempted. (I'm sure you've heard about the pre-empted Linux kernel) So with everything running with near-identical process traits, problems like resource starvation and priority inversion simple do not happen. They can't happen, in fact, and that makes the L4 system especially well-suited for embedded systems as well as hard real-time systems.
But this comes at a tradeoff. Since the kernel is no longer running in ring0, the speed of system calls is dramatically reduced. However, because interrupts are handled in a logical manner, system responsiveness is much faster. It's a tradeoff, like most things in computer software.
It will be interesting to see, as this kernel matures, how well the operating system stacks up against Linux.
http://en.wikipedia.org/wiki/L4_microkernel_family
yeah, I saw Rev OS, it wasn't scrapped. They just designed their kernel in a way which is which makes debugging hard, and thus really long development time. Lately it's looking good though from what I've seen in debian hurd
I might as well quote this too, which I think this story most likely refers to (posted on 27 jan~):
This uses a lot of advanced words I have no idea what they could mean though, but I don't mind as long as someone does and writes an article
Still a long way to go. Not much one can do except wait... or send in patches if you have kernel hacking experience!
This article explains the philosphy behind L4, and how it's different from Mach.
Reminds me of the Dilbert comic strip ...
I've been boycotting Dilbert since its authors became BSA propaganda whores.
Well, this is fairly wrong but some of the truth is there.
The x86 uses rings but everything else just uses the supervisor vs user state (since that is all anyone uses the x86 for: rings 0 (supervisor) and 3 (user)).
You can be interrupted in ring 0 (on x86) or other architectures' kernel privilege level. They usually have an interrupt state flag that needs to be set but, as far as I know, this never has to do with privilege level (except that most interrupts turn it off so that you can clear the interrupt).
There is no "ring 4". On x86 it is "ring 3" (there are 2 bits for the ring level) and other chips just have "user mode" (hence, this is the generic term for this state).
Resource starvation and priority inversion have nothing to do with the notion of CPU privilege levels and can both occur on L4.
The real power to a microkernel comes from the modularity. It is much easier to maintain several small programs than one large one. Plus, it means that any problem in one of them harms nobody else (and that process can later be restarted instead of bringing the whole system down like Linux would with a bug or faulty driver). Additionally, a lean microkernel can stay resident in CPU cache so all kernel code can be run without memory latency overhead (only memory access and device access causes a problem).
The disadvantage is that the additional level of indirection in the message-passing between processes takes longer than just jumping to the kernel to execute a function and then returning (it isn't quite that simple but you get the idea).
What L4 seeks to do is bring all levels of processing out to ring4.
Do you mean ring3? Because there are only rings zero through three (which makes four). Somebody fails their computer counting!
As with NextStep in its days, the MacOS X "microkernel" was mainly based on Mach because it allowed fast development. The concept is called a "monolithic microkernel": a microkernel with just one "server" doing just about everything.
You will realise how long it took the (handful of) HURD developers to port to L4. I don't think Apple has any ambitions in that direction. It just wants to sell a working system.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
On BeOS, when the sound subsystem crashed you would get a message informing you of this, and it would automatically attempt a restart. On Windows or Linux when the sound subsystem crashes, the odds are you've got a kernel panic (since the drivers run in kernel space).
I am TheRaven on Soylent News
Windows XP's kernel is a modified microkernel design. Most people are unaware of this, but it means that the vast majority of the code your applications call are also running in user space. For example, on Windows 64 machines, there's a Windows 64 environment, a Windows 32 (WoW64) environment, and so on. In the olden days, there were DOS VDMs, POSIX, and OS/2 sub-systems.
Not every Windows or Linux driver is kernel-space, but most are.
However, with adequate testing, crashes due to buggy drivers are rare. If you choose to run crap drivers, of course you'll see problems. Including on
Andrew van der Stock
You're describing the bootstrapping problem, which if I recall correctly is actually described on the GNU website, somewhere.
To answer your question, the GNU devs started out with proprietary operating systems -- primarily SunOS, I think -- and took advantage of the modularity of UNIX to replace one utility at a time. This is why the kernel was the last piece -- because most of what makes a UNIX system run actually resides in user space.
Attempts to create free versions of other OS types -- ReactOS comes to mind -- have a harder time following this example, because most other operating systems are not designed in such a modular way. So they start with the kernel.
guess nobody bothered to g**gle it: New kernel for Darwin:
The kernel is not implemented as true microkernel. There is seperation, but the message passing is limited to IO request packets that are sent to and from the HAL from (properly written) drivers. The drivers run in the same thread but in a different execution context / ring (IIRC through a "door").
But drivers that require "fast IO" are running in the same address space as the kernel.
So while the IORP-using drivers shouldn't be able to take the system down, I wouldn't call it a microkernel exactly.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
"Mozilla" (Netscape) wasn't killed because of the rewrite. They were killed because version 4.7x sucked, and they couldn't compete with free as in beer.
The article isn't saying that they could only just now boot HURD, it is saying that they moved from the Mach microkernel to the L4 microkernel, and since the move they have just been able to run programs.
No, he's referring to this story: GNU/Hurd Web Server Online
I remember that slashdotting the first time around... pretty funny to link a beta OS up like that to be taken down in minutes by the hoard.
I think it's really nice how Linux, by making the code accessible, allows smart people to improve it in ways that were not originally in the plan.
The Hurd website, wiki, etc. haven't been updated in years.
At a more fundamental level, there's a design disaster in the making here. L4 seems to make the same mistake Mach made with interprocess communication - unidirectional IPC. This design error is called "what you want is a subroutine call, but what the OS gives you is an I/O operation". This is a crucial design decision. Botch this and your microkernel performance will suck.
QNX gets it right - the basic message-passing primitive is MsgSend, which sends a message and blocks until a reply is received (or a timeout occurs). The implementation immediately transfers control to the destination process (assuming it's waiting for a message), without a trip through the scheduler. That's crucial to getting good performance on real work from a microkernel.
Mach botched this. Mach IPC is pipe-like, with one-way transmission. And that's a major reason Mach was a flop. (Note that the version of Mach used for the MacOS isn't the final "pure Mach", it's a Berkeley BSD UNIX kernel with Mach extensions.)
Why does this matter so much? Because if send doesn't block, when you send, control continues in the sending process. Later, presumably, the sending process blocks waiting for a reply. But who runs next? Whoever was ready to run next. If you're CPU-bound and there are processes ready to run, every time you do a message pass, you lose your turn and your quantum, and have to wait. So programs with extensive IPC activity grind to a crawl on a loaded system.
But if message passing is tightly integrated with scheduling, a message pass doesn't hurt your thread's CPU access. Control continues in the new process with the same quantum (and in QNX, the same priority by default, which avoids priority inversions in real time work). Now message passing is only slightly more expensive than a subroutine call, and can be used for everything.
There is a big literature about Mach, Minix and related underperforming academic microkernels, while the key architectural details of the commercial microkernels that work (basically QNX and IBM's VM) aren't well publicized. But you can dig the information out if you work at it.
Yes, MacOS X is Mach-based. Mach, however, is not really a microkernel in the true sense of the word. Compared to L4's size, Mach is a huge monster. Somebody else already provided a link to an introductory (if old, from 1996) article by the L4 creator Jochen Liedtke.
As a matter of fact, the L4KA group is looking into this. See, for example, this thesis currently in progress.
The main benefit is that L4 is actually a true microkernel. It has something like seven system calls that basically handle interprocess communication and address spaces. Everything else needs to be done by user-level processes. L4 separates policy from mechanism, that is, it provides the basic mechanisms and leaves it to the actual OS implementation what policies to implement. It has a very tiny memory footprint and about every optimization possible to operate extremely fast. This is important as in a microkernel environment, much more IPC takes place. Mach sucks here as their IPC operations are terribly slow. L4's IPC speed and its general size show that it's actually feasible to write a real microkernel without taking a non-negligible performance hit. L4Ka::Pistachio is an L4 implementation done completely in C++, which makes code maintenance much nicer, and goes to prove that it is in fact possible to create an efficient microkernel implementation in C++.
It would probably make sense for Apple to look at L4 (as it does for the Hurd), but of course L4 provides much, much less than Mach does (which is good! It's a microkernel after all) and therefore Apple (or, maybe, my friend working on that thesis I mentioned above) would have to reimplement all low-level system services besides address space handling and IPC around L4, in user-level processes. It is probably feasible, but still a long way away.
5% overhead for running a system that has all the features in reliability alone has got to be well worth it.
5% overhead in the system calls only. In their own timeslice, threads run without any performance penalty, up to the point where they need to IPC some server task like a file server or so.
So it depends if your application is more I/O or compute bound.
But you're right: 5% is next to nothing, even on low-end embedded platforms.
cpghost at Cordula's Web.
Actually the machine never died, just the pfinet server.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!