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

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