Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Hurd Traffic #51 For 7 Jun 2000

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
-- Linus Torvalds, 1991

Table Of Contents

Mailing List Stats For This Week

We looked at 35 posts in 117K.

There were 19 different contributors. 6 posted more than once. 5 posted last week too.

The top posters of the week were:

1. Microkernel Vs. Exokernel

28 May 2000 - 2 Jun 2000 (11 posts) Archive Link: "RE: Samba"

People: Kevin MusickNeal H WalfieldKevin MusiclNeal WalfieldOKUJI Yoshinori

In the course of discussion, Kevin Musick mentioned, "I'm also curious about microkernel architecture. I've worked with Mach quite a bit, and in general I support its use with the Hurd. I also know that, in a multiserver environment, the number of IPC messages required decreases performance, because each message operation involves an expensive context switch. MIT developed an "exokernel" a few years back, which essentially provided only an abstraction of the underlying hardware, leaving most traditional operating system services left to execute in user space. Wouldn't it be theoretically possible to implement Mach's process management, memory management, and IPC mechanisms as some form of protected programs running in user space on top of this "exokernel?" I'm not asking anyone to work on this, or even look into it. I'm just curious if such an approach even sounds plausible." Neal H Walfield replied:

What do you think using an exokernel will gain us?

If we reimplement mach over an exokernel, it will only decrease the microkernel's portability -- we now have a dependency on an exokernel rather then a generic piece of hardware.

Additionally, it will not increase performance; the current killer with the hurd/mach is the number of context switches to do any amount of work (look in the archives for a discussion of this topic). Will an exokernel decrease the number of context switches? Unlikely, however, I am open to suggestions.

With regards to portability, Kevin asked, "What's the difference? Either you port the Mach microkernel or you port the exokernel. In either case, you have localized machine dependent operations to a small portion of the overall system code." While in regard to performance, he said:

The very goal of the exokernel design is to reduce the number of context switches required.

Check out the site at This gives a brief introduction. They implemented a Web server on the kernel, called Cheetah, which ran eight times faster than NCSA. You can also obtain volumes of information by going to and doing a search on "exokernel."

Neal replied, "An exokernel is not a microkernel. Although they both have similar goals, minimize what the kernel has to do, they approach the problem quite differently. A microkernel attempts to manage the low level resources and export an interface. An exokernel, on the other hand, merely wraps the resources in a security blanket and exports them to the applications directly. This would require a hurd library to provide the current mach environment, which could increase context switches even more. This is, of course, all speculation; if you create a proof of concept and prove me wrong, more power to you. It is my feelings that to use an exokernel will require nearly all of the mach kernel to be reimplemented over it, however, I am very interested in what your ideas are."

Neal's post spawned several threadlets at this point. To the idea that an exokernel would require even more context switches, Kevin replied, "I'm assuming that the hurd library(ies) that implements Mach services simply runs in user space. Consequently, for certain operations, say perhaps an IPC send() or recv(), that a context switch would not be required." Neal replied that he'd been referring to the IPC, which took place entirely in the kernel. He added that no matter what, changing tasks would require a context switch in order to access protected memory, etc.; Kevin replied that as far as he knew, IPC took place outside of the exokernel. Traditional operating system services would be implemented by libraries. He added, "You will never eliminate task switching in a multitasking system. I'm not referring to the context switch that occurs when scheduling another task to run. I'm suggesting that sending an IPC message, for instance, might be accomplished by the libraries without having to trap to the kernel." There was no reply and this threadlet ended.

However, to Neal's earlier statement that an exokernel would require nearly all of the mach kernel to be reimplemented over it, Kevin replied, "Agreed. I am not dissatisfied with Mach, although it is an aging microkernel and if there were significant, tangible benefits to the end user of an alternative design, I think it's worth speculation. I like the Hurd and I applaud its architecture over more monolithic systems such as Linux. End users, however, won't care about conceptual superiority -- they'll look for real world justification for choosing a particular platform." Neal replied, "I am throughly dissatisfied with Mach; it has many shortcomings that need to be addressed before it will ever be ready for end users. I believe that they will only be fixed by 64-bit hardware." Kevin replied:

I believe this is true of GNU Mach. The Linux glue code is a giant bandaid. There is no SMP support. No native PCI support. User space device drivers have been disabled. Yada, yada, yada. However, in general, Mach has already been used in commercial systems. NextStep was fairly successful as a Unix desktop. Apple's OS/X and OSF/1 are also Mach-based. Rashid, Barrera, and other CMU members of the Mach project, who were lured away to Microsoft R & D, did many research projects with Mach. They ported Mach to the Intel Paragon, supporting two thousand parallel processors and developed an enhanced virtual memory subsystem (Odin) for accommodating such massively parallel architectures.

That said, Mach is still aging and there may be a better long-term alternative.

To Kevin's 'yada yada yada', OKUJI Yoshinori chastized, "Then, why don't you improve it, if you really think GNU Mach sucks? IMO, the Linux emulation is not so bad. Don't mistake me. The reason why I say that is _not_ because I did some work on it, but because it was (and is) a very practical solution. Even if GNU Mach would support user space drivers, who could implement them? Note that neither Hurd nor Mach is a vaporware. We should find a realistic solution." He added, "You are ignoring the fact that successful projects are based on Mach 2.5 but not Mach 3.0. AFAIK, there is no commercially successful project which uses multiple servers on a microkernel, except for QNX."

2. Unfinished 'procfs' Translator

31 May 2000 (1 post) Archive Link: "procfs"

Topics: FS: procfs

People: Neal H Walfield

Neal H Walfield announced reluctantly:

A while ago, I created a procfs translator (an emulation layer for linux proc compatibility). I have not done any work on it in the last three months, therefore, and thanks to John, I am releasing it prematurely. For the most part, it works (ie does not segfault), however there are alot of missing features.

If you want to have a look at it, head over to

There was no reply.

3. Simplifying Translators

31 May 2000 - 4 Jun 2000 (3 posts) Archive Link: "[RFC] translators"

People: Marcus BrinkmannNeal H WalfieldOgnyan Kulev

Neal H Walfield had found from his several experiences writing Hurd translators, that the hardest parts were figuring out which functions to override, and finding the correct prototypes. He suggested a change to the current method of letting the linker do the function overriding. He felt the translator should simply register its functions, device driver style. Ognyan Kulev agreed with this. He felt the current situation was a hack to allow object oriented design, but he felt Neal's solution would be much more natural for programmers, and would make it easier to write translators in C++ etc.

Marcus Brinkmann was not enthusiastic. He pointed out that the difficulties Neal pointed to were actually inherent in the design, and were not simply gratuitous complexity. He went on:

Of course it is trivial to put such a scheme on top of the Hurd libraries, leaving the choice to the programmer (you could write such a thing for yourselve, if you really want to).

However, is it really useful? If only done partially, it might lead to the wrong conclusion that you only need to implement those functions and are fine. This is only partially true. For example, some default implementations in diskfs assume that multiple links to a file are allowed, which is not true for all filesystems, so you need to override these functions with your own implementation. Of course you can add these functions to the table, but you must document in detail when they are needed (or you are back to reading the source).

So, you might end up adding all functions to the table that are provided by the library (how do you know the default implementation is proper for all possible cases?), or you reduce it to the common ones, in which case you suffer from inconsistency.

Well, personally, I don't think there is a problem with the way things are. The interfaces you have to define are documented in the hurd manual, and if not, then they should be. Details for uncommon cases will always have to be worked out from the source of the libraries anyway.

The exact semantics of the Hurd servers and libraries are more complex than the linux vfs.

There was no reply.

4. Hurd Survey

3 Jun 2000 (1 post) Archive Link: "PLEASE Respond ASAP"

People: Jenny Hang

Jenny Hang was doing a school project about the Hurd, and wanted people to fill out her online form. The form asked:

  1. How many years have you been involved in the open source movement? And why did you decide to get involved in open source projects? Your drives?
  2. How long have you been working on HURD? How did you get involved in HURD? What rewards do you receive from working on HURD?
  3. What other open source projects have you been involved in before HURD? What were they?
  4. How is HURD organized? Is there a hierarchical structure to the organization? How does the organization fund its project?
  5. What area of HURD are you currently working on?
  6. How many HURD developers do you actively communicate with? What are your methods of communication? Do you communicate effectively with each other? Do you find any problem(s) communicating with one another?
  7. How do you coordinate your development of HURD? Is there a manual that every developer has to follow? Is there a certain way that developers have to code?
  8. How do developers at HURD coordinates with other developers from GNU and others such as the GNOME developers?
  9. Due to the constant changes on HURD, how can developers keep current with new HURD version? How is documentation to the HURD project handle?
  10. How are bug-fixes that are posted reviews? Are there peer-reviews among developers to ensure that bug-fix do not cause more problems?
  11. How do you think HURD fairs against other kernels?
  12. How do you think HURD open source development compares to the close source development of other kernels?

There was no reply on the list.

5. Debian Conference

3 Jun 2000 (1 post) Archive Link: "Zeroth Debian Conference : the HURD"

People: Thierry Laronde

Thierry Laronde announced:

For the one who haven't yet been bothered by my messages : I am the main coordinator of the Zeroth Debian Conference, that will be held in Bordeaux, from 5th to 9th of July 2000.

I have (finally !) taken the time to browse the archives of the list, and found a couple of messages discussing about the conference.

One thing must be clear : the HURD developers, as far as I know, are not very numerous ; I know that Neal and Juergen will be here. But there are other things that I know :

Juergen is right : the main goal is to allow people to get in touch with others (other developers, other projects, etc...) ; and there is no need to be scared, Juergen : that's Debian, that's Free Software, so this won't be "too organized" ;) But just in order to allow non-developers_yet to identify the ones they want to discuss with, we need a kind of presentation of the Debian work about the HURD, so that people can say : "I want to go there, because they discuss about the subject I want informations about".

My role is only to provide opportunities and facilities : not to define in details the program : that's up to you ! (but as I'm one of the people wanting more informations about the HURD, I will make some efforts in order to satisfy my personal curiosity...).

For problems or questions, don't hesitate to get in touch with me.

There was no reply on the list.

6. Porting The JFS Journalling Filesystem To The Hurd

4 Jun 2000 (2 posts) Archive Link: "Hurd file system"

Topics: FS: JFS

People: Marcus Brinkmann

Lars Roland said that in addition to his work on the JFS Journalling Filesystem for Linux, he had also ported it to the Hurd in his spare time. He wanted to know if this was a good idea, before putting a lot of time into it. Marcus Brinkmann said that he and others would be happy to answer his Hurd questions, and even test code when they had the time. He added that JFS would be a great addition to the Hurd. The more filesystem translators the better, he said, especially journalling filesystems, since they've been hotly discussed on the list.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.