GNU/Hurd Gets POSIX Threads

Uh... by Anonymous Coward · 2002-09-30 03:35 · Score: 1, Informative

POSIX threads is an extension to POSIX.1 (IEE1003.1), known as either POSIX.1c or IEE1003.1c.

The POSIX threads API is actually fairly small and simple, and works well across different implementations (E.g. kernel threads v's user space threads etc.).

Not knowing much about HURD I don't know if the kernel already had threads support, so I don't know how much work went into this implementation. Does anyone here know if this is a complete user threads implementation, or is it a wrapper over some form of "native" threading scheme?

an excerpt by Anonymous Coward · 2002-09-30 03:42 · Score: 4, Informative

here's an excerpt:

Neal Walfield [interview] announced the first release of RMGPT, which "is (or
rather, aspires to one day be) a complete, portable implementation of IEEE Std
1003.1-2001 threads [also] known as POSIX threads." I was excited to read Neal's
announcement email, as this is a big step forward for the GNU/Hurd project. With this
new pthreads library, it will soon be possible to run complex software packages on the
Hurd, including the GNOME and KDE desktops, the OpenOffice suite, and the Mozilla
web browser.

Regarding the name, RMGPT, Neal explains, "Most new program names are a bunch
of letters stuck together. Only later does it become an acronym and the words
become bound. This is boring; each new release of RMGPT will offer a fresh, new and
exciting expansion of the 'acronym'." For this first release, RMGPT stands for
"Rubbish, I asked for mine with Minced Garlic, Please Take this back".

Neal was kind enough to answer a few questions about his pthread efforts. Read on to
learn more...

JA: What does this first release of a POSIX threads implementation mean for the
GNU/Hurd project?

Neal Walfield: Beyond adding another important, commonly used interface, I think
that a pthread implementation represents a large step forward in the public eye: we
should soon have many more major software packages including GNOME, KDE,
OpenOffice and Mozilla. The perceived lack of support for complex software was
often assumed to be a result of a general lack of maturity on the part of the Hurd itself.
In certain respects, this is correct: until now, there was no pthread implementation;
there are still limits on the maximum size of file systems; and Mach only supports a
limited amount of hardware. On the other hand, the Hurd was not designed to just
clone an existing interface; the goal was to study what was available, explore the
flaws and then redesign it. From this perspective, I think that Hurd has been very
successful: the translator concept is incredibly powerful and flexible; and security
wise, Unix just cannot compete.

JA: You say that RMGPT aspires to one day be a complete, portable implementation
of IEEE Std 1003.1-2001 threads, also known as pthreads. How complete is it today?

Neal Walfield: With respect to the pthread interface, all of the prototypes are present;
implementation wise, I think that we are about ninety percent done. The last ten
percent consists of advanced scheduling features (e.g. mutex priority ceilings) and
process shared resources (the ability to share, for instance, a mutex between multiple
processes just using shared memory). Neither of these are terribly important from a
usability perspective as not many applications take advantage of them, however, I am
interested in implementing them. I think that the ABI should remain stable. I am
relatively confident that the data structures are flexible and expandable enough to
cover most future changes.

There are also bugs, however, the implementation seems to be relatively stable under
normal application load. Several people have compiled some different packages over
the past few days and they seem to be crashing of their own accord, not pthreads'.

JA: How long before you expect RMGPT to be fully completed?

Neal Walfield: The goal right now is to stabilize and get some people to test the code.
Then we can concentrate on finishing the scheduling and process shared attributes
and worry about optimizations. It should be integrated into the Debian unstable system
some time this week. Applications will follow.

JA: How did you come up with the ever changing acronym RMGPT?

Neal Walfield: Take, for instance Perl and UVM: the authors are victims of their own
genius: even though they stated that the name did not mean anything in particular,
people have tried to guess what their real intentions were thus, de facto interpretations
have come into use. I am blatantly telling everyone that it RMGPT will have a new
meaning every release: life does not get any simpler. Plus, it will be less stress for the
users.

JA: How close now would you estimate the GNU/Hurd is for another official release?

Neal Walfield: Getting closer everyday. In fact, I hope that by this time in October,
we will be a whole month closer.

Re:My apologies to RMS by jbailey999 · 2002-09-30 03:51 · Score: 5, Informative

The core design of the Hurd still isn't in use by any Free OS out there. The idea is to have as much as possible sit in userspace, and to have "translators" that allow any user to add hooks into the filesystem (making cool things like ftpfs and nfs possible without requiring root, and without requiring the sysadmin to install it for you).

If you're interested, take a look at Towards a New Strategy of OS Design - It explains what we're doing different with the Hurd, and what the core servers are used for.

Tks,
Jeff Bailey

Re:bad news for Linux? by photonic · 2002-09-30 03:57 · Score: 2, Informative

IANAKG (i am not a kernel guru), but as i understand the Hurd is running on top of Mach which is a microkernel. This is supposed to have some (at the moment still theoretical?) advantages such as running drivers in user space (and some potential speed improvements??).

I believe the idea is to replace Mach in the end by the more advanced L4 kernel, which is an area of active research.

--
karma police: arrest this man, he talks in maths; he buzzes like a fridge, he's like a detuned radio. [radiohead]

Re:My apologies to RMS by Anonymous Coward · 2002-09-30 03:58 · Score: 0, Informative

The core design of the Hurd still isn't in use by any Free OS out there. The idea is to have as much as possible sit in userspace, and to have "translators" that allow any user to add hooks into the filesystem (making cool things like ftpfs and nfs possible without requiring root, and without requiring the sysadmin to install it for you).

Yeah, thats traditionally called a "micro kernel" The fact that the HURD is doing it doesn't mean it is a new concept. CS researchers have been playing with micro kernels for over 20 years. There are lots of operaring systems that already implement micro kernels.

I won't even go into the overhead inherent in a micro kernel message passing architecture.

The link is /.ed by smallpaul · 2002-09-30 04:00 · Score: 3, Informative

Here is another one

Hurd is a multi-server by Per+Abrahamsen · 2002-09-30 04:03 · Score: 4, Informative

The idea of a microkernel is to have multiple seperate servers running on top of it, providing some clear seperation between different parts of the system. Hurd is the only one of the three that does this, MkLinux and Darwin are both implemented as a single monolithic server on top of the Mach microkernel.

Also, they are based on different versions of Mach. I believe Darwin is based on 2.5, MkLinux on 3.0 and Hurd on 4.0 but don't quote me on that.

Re:Given the amount of work ... by Anonymous Coward · 2002-09-30 04:15 · Score: 1, Informative

Hi!

> The operating system formerly known as, GNU Hurd is now:

There has never been a operating system called the GNU Hurd (although some very old documentation states so). The operating system is the Hurd-based GNU system, or GNU/Hurd for short. As the Hurd is part of GNU, it can also simply be called the GNU system. I think in the glibc documentation it is called this way.

Cheers,
GNU/Wolfgang

Baka by Kourino · 2002-09-30 04:30 · Score: 2, Informative

This is a userspace library implementing Posix threads. Linux, I might point out, doesn't natively implement pthreads in the kernel. You might also consider that Hurd's design isn't monolithic, so of course there's not going to be much in the kernel. Please go read up on things before you flame them. This may be /., but it doesn't give you full rein to be clueless ~_^

(By the way, sorry to burst your bubble, but MORE PEOPLE THAN LINUS WORK ON LINUX. Most of the really fun threading stuff has been in Ingo's domain, of late. I really need an old, cheap computer to run 2.5 on and hack around ... ;_; )

Re:My apologies to RMS by Ektanoor · 2002-09-30 04:37 · Score: 4, Informative

Hurd is an OS with a much more "correct" architecture ideology than Linux and BSD. In its core it is much more universal and modular. Unfortunately, there is a huge gap between the paper and reality. The way it has been developed showed many HURDles among the GNU community. The more lavish, intellectual and less pragmatic approach to development made HURD a pariah. That's why Linux came up and ran over it. Being a traditional monlithic kernel that nearly carried all the ills of a 20 year kernel ideology, the penguin won just by being more closed to Earth.

However I hope that one day HURD will be able to hit the stands. It has been a pitty to see such a good idea living such a sad life. Frankly, we have been quite poor in kernels for the last years...

Re:What about exokernels? by gnu_wolfgang · 2002-09-30 06:37 · Score: 2, Informative

Hi! Maybe someone might disagree, but in my understanding the Exokernel project was basically a second-generation microkernel, similar to L4. Cheers, GNU/Wolfgang

Re:Good ! by gnu_wolfgang · 2002-09-30 07:05 · Score: 2, Informative

Hi! Well, GNU Mach 1.x uses the drivers from Linux 2.0, OSKit has the driver support from Linux 2.2. We support the most common stuff, but some things are completely missing, like sound card drivers. So the hardware support is nothing to be proud of, and is also not of high priority, as it is strategically better to care about the core components first. As long as it is possible to run the systen on most computers, of course. :) Cheers, GNU/Wolfgang

Re:Given the amount of work ... by uid8472 · 2002-09-30 07:11 · Score: 2, Informative

Sorry, but the start tag <os derived="unix" derived="mach"> clearly violates the XML well-formedness constraint of unique attribute specifiers; or, in the words of the XML spec, No attribute name may appear more than once in the same start-tag or empty-element tag. I guess a proper description of this OS will have to wait for another day and another DTD...

Re:What about exokernels? by Arker · 2002-09-30 08:33 · Score: 3, Informative

The main purported advantage to microkernels are stability and flexibility, along with all the other good stuff that comes from modularity of course. A microkernel can run different personalities which present what we generally think of as a kernel interface to the outside, as user processors. So for instance the same box, the same microkernel, could be running a Windows personality for one user, a Mac for another, *nix for a third, all with effective root priveliges if need be, but without actually being able to do any damage outside their virtual sandbox... from a developers standpoint it's an incredible potential, I really can't do it justice but you should read this.

The potential here has never been exploited, unfortunately. Every existing microkernel AFAIK has wound up ditching the microkernel design at some point down the road, aiming to produce a particular personality (whether win32, the near-BSD personality of Darwin, etc.) and integrating key features of that personality into kernel space for performance reasons, essentially nullifying the whole microkernel idea. The HURD is the exception, and yes it's been a long time making, and it's still not ready yet, but if it ever does hit primetime it will be a very interesting system.

As to the performance hits, you're right that they are there, however there is a long history of some very smart people working on that problem, and it's gotten a LOT better. I think the current performance winner among microkernels is L4 and you can run a Linux personality on it without seeing a noticeable performance loss over running real Linux on the same processor - that's some very nice optimisation. There has been talk of porting the HURD to run on L4 instead of GNU Mach at some point, I think actually some people working on the problem areas, but for the moment there is no need - HURD is still very much in the developers only phase, it's not for production systems yet so performance isn't critical.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.

Re:Darwin and MkLinux? by Matthias+Wiesmann · 2002-09-30 11:42 · Score: 3, Informative

Here's where I think he's wrong. What he's describing here is how it works in Darwin (and NT) yes, but only because they moved those systems back into kernel space. But the way it works on a proper microkernel system (like the HURD) doesn't just run these things in a separate address space but at a different privilege level, so instead of crashing the kernel you simply crash a daemon and have to restart it. This does mean drawing the lines a little differently than they have, of course.

The problem, as I understood (can't remember where I read this) it is that in practice restarting the deamon that handles the swap disk is very tricky. Assume demon A is responsible for the swap infrastructure. If A crashes, the kernel has to restart it - but it has to do this without paging in or out any page (swap is not available anymore). Demon A must probably be reloaded from the file-system - but by design a micro-kernel should not know about file-systems.

I don't know if the Hurd can manage this kind of recovery. What I'm sure about is that such an recovery mechanism would be complex - and implementing it hard work.

I'm not convinced that the effort needed to enforce this kind of fault tolerance would be reasonable - on one hand you could tolerate failures of the Unix personality, on the other this would add complexity to both the kernel (to be able to restart demons/servers) and to the servers (they would need to be able to restore their state at restart) - IMHO, for a single OS machine, it sounds overkill.

One case where I think such an architecture makes a lot of sense is if you implement many virtualised OSes on one single machine. For instance you would have n logical servers that share one micro-kernel - in this case, if one of the virtual servers fails, the others are not affected.

15 of 382 comments (clear)