First Program Executed on L4 Port of GNU/HURD 596
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!'"
Re:Mach Microkernel vs L4 (Score:3, Informative)
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.
Wikipedia link (Score:5, Informative)
Re:Linux (Score:2, Informative)
Well, it's not that much :) (Score:5, Informative)
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!
Re:Mach Microkernel vs L4 (Score:5, Informative)
Dilbert == BSA whore (Score:4, Informative)
I've been boycotting Dilbert since its authors became BSA propaganda whores [bsaengineers.com].
Re:Well, it's not that much :) (Score:5, Informative)
L4-Hurd is pretty nifty, I think. Of course I run Gentoo and whatnot personally for the usability aspects, but I've been following the L4-Hurd port for a while now and this is an amazing little bit of news.
I can't wait to start experimenting with the new features. This is really cool.
Here's a coral cache link to the HurdOnL4 [nyud.net] Wiki page which I set up last summer. It's slightly out of date, but provides a lot of background behind whats going on and some basic information about the build and boot process.
When you retrieve the CVS sources, read the README and all the docs because they contain the most up-to-date information available about building the system.
Re:Mach Microkernel vs L4 (Score:5, Informative)
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).
Re:Mach Microkernel vs L4 (Score:2, Informative)
Do you mean ring3? Because there are only rings zero through three (which makes four). Somebody fails their computer counting!
Re:Mach Microkernel vs L4 (Score:3, Informative)
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.
Re:Benchmarks? (Score:4, Informative)
Re:Benchmarks? (Score:3, Informative)
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
Re:I'm assuming RMS will switch (Score:4, Informative)
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.
there is a research project to port darwin (Score:4, Informative)
guess nobody bothered to g**gle it: New kernel for Darwin: [uq.edu.au]
No. (Score:3, Informative)
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.
Re:Dilbert == BSA whore (Score:5, Informative)
> Please think it through, Dilbert is right. How can you not support the BSA's actions ?>/tt>
Easily. I support its basic principles - protecting its memebers' copyrights - but its actions are indefensible. Take some of the following examples. In 2003 they sent a letter to a German university demanding they take down infringing software from their site. The software? OpenOffice. Also in 2003 it attacked Massachusetts, the only state holding out against the DoJ's settlement, for adopting an open source policy when no such policy existed. In 2000 when I was working for a small company in London, we received a letter threatening to make us "the focus of a BSA investigation" if we didn't get licenses for all the pirated software in use at our offices. We had licenses for all our proprietary software - namely Informix and Solaris. In 2002 they attempted to raid kickme.to's offices in order to find information about their customers, when kickme.to is just a redirection service with no hosted content of its own. Only last month they published a whitepaper calling for the enforced cooperation of 3rd parties (i.e. ISPs) with rights holders. In other words they want the existing, much abused, DMCA subpoena and takedown notice fortified. In 2001 they said the cost of piracy was $3 billion. In 2003 they said it was $29 billion. I guess $3 billion is not enough money to make the headlines, so they had to re-engineer their spurious mechanisms to produce a better figure.
In short the BSA is a bully, a liar and its actions are, as the grandparent poster argued, indefensible.
Re:Dilbert == BSA whore (Score:5, Informative)
Basically, they are a roving band of pirate lawyers looking for plunder. Mafia tactics, that border on harassment, not these "do-gooders of Copyright laws" you proclaim.
Re:Benchmarks? (Score:2, Informative)
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.
Re:what about second? (Score:3, Informative)
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.
Re:Benchmarks? (Score:3, Informative)
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.
Can't anybody over there write an OS? (Score:3, Informative)
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.
Re:Mach Microkernel vs L4 (Score:3, Informative)
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 [l4ka.org] by the L4 creator Jochen Liedtke.
As a matter of fact, the L4KA group is looking into this. See, for example, this thesis [ira.uka.de] 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.
Re:Mach Microkernel vs L4 (Score:3, Informative)
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.
Re:what about second? (Score:3, Informative)
Actually the machine never died, just the pfinet server.