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!'"

Comments

Re:Mach Microkernel vs L4

[Anonymous Coward]

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.

Wikipedia link

[ceeam]

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

Well, it's not that much :)

[Leffe]

Let me quote from the l4-hurd mailing list (posted 02 feb):

At Wed, 02 Feb 2005 01:12:44 -0500,
"B. Douglas Hilton" wrote:
> So, how much longer before Python will build on L4-Hurd? :-)

If you mean "building" as in "compiling it", that should be possible as soon as we ported the dynamic linker, or at least made sure the dynamic linker "builds" (ie, "compiles"), if python can be cross-build.

If you mean "building" as in "compiles _and runs_", then we are talking about a much longer time-frame :)

With my glibc port, I can already build simple applications, but most won't run because they need a filesystem or other gimmicks (like, uhm,
fork and exec), and I only have stubs (dummy functions which always return an error) for that now.

So, for the time being, a measure of progress is what functionality is implemented: drivers, filesystem, signal processing, process
management, etc. Luckily, we have so much existing knowledge to draw from (the Hurd on Mach source code, for example), that I am carefully
optimistic that progress can kick in very quickly once we have sorted out some fundamental (low-level) design issues and got a sufficient
understanding of the details of the system.

Thanks,
Marcus

I might as well quote this too, which I think this story most likely refers to (posted on 27 jan~):

Hi,

with the changes of today, the glibc patch set in CVS supports startup and initialization up to the invocation of the main() function - this means important things like malloc() work.

Of course, there is a lot of cheating going on, and the implementation is full of gaps and stubs. But this step forward means that we can do
easy testing by just writing a program and linking it to glibc, and run it as the "bootstrap filesystem" server.

TLS/TSD seems to work without any problems - important things like the default locale are set up correctly, and thus strerror() works. __thread variables are supported, glibc uses them itself.

There were a couple of fixes and extensions needed in wortel and the startup code, but it wasn't so much. My understanding of the glibc code has reached an all-time high (not that this required much ;)

If you want to reproduce all this, you need to configure, make and install the software as usual. It is important that your compiler can find the installed header files afterwards! Only then you can reconfigure your source with "--enable-libc" and try to build the C library according to the README.

Static linking against this new libc should be possible after (manual) installation, I guess, but I always use a very hackisch and long gcc
command line to cheat myself into a binary that I can then use as "filesystem server" (the last one in the list) in the GRUB configuration. See the README for details.

I think that this basically concludes the first step of the initial bootstrap phase. By being able to link a program against glibc, and
by booting all the way up to that programs main() function, we can now easily explore and develop the system in any way we want.

The dinner is prepared! :)

Thanks,
Marcus

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:Well, it's not that much :)

[The_Dougster]

Wow, something I wrote actually trickled back into /. Amazing. I was just joking about Python, of course.

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

[joib]

This article explains the philosphy behind L4, and how it's different from Mach.

Dilbert == BSA whore

[Anonymous Coward]

Reminds me of the Dilbert comic strip ...

I've been boycotting Dilbert since its authors became BSA propaganda whores.

Re:Dilbert == BSA whore

[ProfitElijah]

> 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

[AbbyNormal]

Have you ever received a letter from the BSA? Coinicidentally, we only received one after we let one of our MS action pack subscriptions lapse (but purchased another). In not so many words, they threatened with forcing us to prove we've destroyed our remaining unlicensed copies of software. Ironically on the same day, we received our renewal receipt for the Action Pack. You can imagine all the "warm and fuzzies" the BSA letter gave us.

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:Mach Microkernel vs L4

[Anonymous Coward]

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

Re:Benchmarks?

[TheRaven64]

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

Re:I'm assuming RMS will switch

[808140]

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.

there is a research project to port darwin

[Anonymous Coward]

guess nobody bothered to g**gle it: New kernel for Darwin:

Apple's Darwin operating system is the open source base for Mac OS X. The underlying kernel is based on Mach. This project requires implementing a replacement for Mach based on the L4ka Pistachio kernel. Since ports of both exist on similar platforms (IA32 and PPC), most of this project will consist of building an emulation layer for Pistachio which can provide system call interfaces to match those provided by the existing kernel. In addition to implementation and testing, performance evaluation will be an important aspect of this project. Since part of the project is already done and the whole thing is quite large, an important aspect wiill be defining a doable subset, in conjuction with anyone doing part of it for BE. Starting early is advised on this project so no late applications will be considered.

No.

[Ayanami Rei]

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.