Hurd Traffic #14 For 8 Sep 1999

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 40 posts in 119K.

There were 19 different contributors. 10 posted more than once. 7 posted last week too.

The top posters of the week were:


1. Searching For Archives Of Design Discussions
 Archive Link: "Previous open GNU/Hurd design discussions?"
People: Pontus LidmanMark KettenisMarcus BrinkmannThomas BushnellMichael Bacarella

Pontus Lidman asked where he could find archives of past discussion of Hurd design issues. In particular, he was interested in:

  • The phasing out of MiG, is there some replacement that is considered? Utah's Flick? Will MiG be phased out from the Hurd source, or from GNUMach development in general?
  • The writing of libmom, are there any particular reasons to not use Mach in the future?
  • The deprecation of shared memory I/O; I seem to recall that the possibility of shared memory I/O is one of the main points in a paper I read about why IPC performance isn't so important anymore (I don't remember the title now).

Michael Bacarella recommended Kernel Cousin Debian Hurd, but Pontus wanted something that pre-dated the debian-hurd list, and pointed out that KC Debian Hurd only went back to June.

Mark Kettenis offered some insights. Regarding the phasing out of MiG, he said, "MiG has it's shortcomings, but there are no concrete plans to replace it with something else. I guess Utah's flick would be a candidate, but this really depends on other things such as moving to other microkernels." Regarding libmom, he added:

libmom has been dropped. The idea is to start making the Hurd less dependent on Mach after the next release. Reasons for moving away from Mach include:

  • Mach is aging and it shows. It doesn't take advantage of modern hardware.
  • Mach isn't the fastest microkernel that's around.

Marcus Brinkmann offered some small info regarding older sources of archived discussion. He said, "Trent Fisher had a Hurd page which seems to be pulled now. There was a mbox archive of some old mailing list for Hurd friends. The list never produced much useful results, which is why Thomas Bushnell pulled the list after a year or so. Well, I don't even have an email address of Trent. I have a copy of the emails, but anyway it won't answer any of your questions below."

More specifically, regarding design decisions, he added, "I don't think much of this discussion happened on a public list."

In general, he advised, "beside the Hurd info file, the overviews on the gnu web pages and the source, asking on this list or on help-hurd is the right thing to do. If you read old mail, it can happen that you read about obsolete concepts, so asking here is better, in my opinion."


2. bsdutils Dependancy Questions
 Archive Link: "bsdutils Debian package -- conflicts?"
People: Marcus Brinkmann

Andrew Stribblehill noticed that bsdutils is dependant upon sysvinit, although sysvinit wasn't in the archive. Marcus Brinkmann replied:

Oh yeah, I did not upload it yet, because I wait for a response of the maintainer. I have finished it though, so you will see a package soon (within weeks).

Neither bsdutils nor sysvinit are absolutely essential, but I put a lot of work in the latter, so better get it and test it when it is available, so I can enjoy seeing people using the results of my bloody nightmare coding nights :)

Oh, a last note: just enter:

dpkg -i --force-install bsdutils_*deb

to force the installation of bsdutils. It doesn't really need sysvinit, as far as I know.

I will try to put a bit of pressure on the sysvinit maintainer.


3. Switching Away From Mach
 Archive Link: "mach deficiencies"
People: A. P. GarciaOKUJI YoshinoriChristopher BrowneAymeric VincentMichael BacarellaMarcus BrinkmannThomas BushnellMatthew Vernon

This was the largest discussion of the week, with 16 posts. A. P. Garcia picked up an older discussion of whether to move away from Mach, commenting, "Speed is IMHO less important than simplicity of design, maintainability of the code base, and stability."

OKUJI Yoshinori replied, "I don't think the design of Mach is simple. And, as for GNU Mach, the maintainability is poor (its code is like spaghetti)"

Christopher Browne added, "One member of the local Linux Users Group has commented that he did some work on some code written by the OSF, who had considerable involvement with Mach. He found their code to be spaghetti-like and otherwise very difficult to maintain. It is not outrageous to consider it possible that there might be some relationship between these factors and Mach being difficult to work with..."

But Aymeric Vincent dissented, with, "I wouldn't be so definite about Mach. I like the way it's programmed, the only problem being that it's `layered'', with all the people who worked on it changing the coding style everytime... I think the introduction of Linux drivers (in Mach4) was the beginning of the end, because Linux drivers are far uglier than Mach (and are not tailored for it, that's the least one can say). Maybe, since GNUMach seems to be in a dead end, we would have less trouble using NetBSD's drivers, which are much much nicer... and closer to Mach."

Elsewhere, Christopher added:

The point is that there has been considerable research done since Rashid left for Microsoft, particularly with L4 at Dresden University, concerning microkernel performance, thereby showing up more clearly some of the advantages and disadvantages.

Note that:

  1. L4 is actually a small microkernel;
  2. OSKit has been showing off that it is useful to create an OS infrastructure surrounding memory allocation schemes in order to be supportive of specialized languages;
  3. Most early microkernels seem to have been monolithic systems, unlike Hurd.

The other point is that it may eventually make sense to throw away the code and create something fresher.

Michael Bacarella replied with his opinion:

I think that theoretically, the Hurd would be much better off ditching GNUMach for L4, but there's a lot stopping something like that.

We're effectively throwing away a lot of work by ditching GNUMach. It is always smart to get rid of something that isn't working NOW than it is to wait awhile until you're positive that it isn't working, but it's difficult to go on something like that because not everyone agrees that GNUMach isn't working. Although it seems that way so far.

The L4 project pages mention their difficulties trying to port servers that use a Mach interface to their kernel. Who feels like rewriting the Hurd's servers? :)

We'd also either have to write new glue code for the drivers, or ditch them altogether and start with new ones.

There are arguably lots of good things from switching to L4 too. A microkernel that is actually micro! More speed, perhaps. Sanity of maintainance, definately. Cleanliness of code, maybe.

Possibly some better publicity for switching, because we's need people!

There were two prongs of discussion forking off from Michael's post. Along one prong, Marcus Brinkmann said:

If people provide patches for support with other microkernels, that would be nice (check with Thomas first for how to do such patches).

I would like to have multiple kernels in the Debian distribution, so you could choose which one you want ot run currently. I don't know hard it is to achieve this. Could Hurd be designed to run on different microkernels without recompilation?

Per Lundberg pointed out that something like a standard microkernel API would be a big help with something like this, but Thomas Bushnell pointed out:

This is extremely unlikely, if you want any real performance. Programs make system calls, down at the root, and one of the key ways that different microkernels affect performance is by changing the syscalls.

You could, of course, do emulation, but then you immediately lose whatever advantages you would have gotten.

Basically, I think that libc, the Hurd, and any statically-linked programs just have to be compiled separately for each kernel.

Marcus replied, "That's still a reasonable set. So I think the best we can do is to make it possible to install multiple sets of these packages for dual boot. Probably through shadowfs. But that's really only a configuration issue, and has little to do with the development of these ports."

That ended the subthread. The other prong of discussion stemming from Michael's post came from Matthew Vernon and led to Michael adding, "A lot of folks shun the Hurd for being microkernel. We don't have much to go by outside of theoretical benefits that will happen -some- day. L4 sounds like it'd be immediately helpful, at least much more than say GNUMach. I know that at least a few core maintainers of the Hurd feel this way."

Elsewhere in that prong of discussion were various URLs to the projects under discussion. There were links to fiasco ( , flux ( , and an article called The Persistent Relevance of the Local Operating System to Global Applications (


4. Patch To Ease Downloading During cross-install
 Archive Link: "download packages in cross-install"
People: Daniel BurrowsMarcus Brinkmann

Daniel Burrows posted a patch, and announced:

The major obstacle to installing the Hurd from a Debian system using the lots-of-packages method has generally been that it's a pain to get all the packages by hand (yes, not *much* of a pain but still nontrivial) The attached patch modifies cross-install to support downloading the files with wget as part of the installation process. It also should support aborted downloads.

In addition, the patch adds a mechanism for parsing additional options on the command-line (this is used for activating the download feature, but I also hooked it into some other options).

I believe that cross-install should continue to work as it does currently if the download feature is not enabled.

Marcus Brinkmann kicked up his heals and replied, "Whoa, that's nice! I'm happy to include it. Thanks for implementing this feature."


5. Downgrading mke2fs No Longer Necessary
 Archive Link: "HELP, HELP, HELP !!!"
Topics: FS: ext2
People: Pontus LidmanDaniel BurrowsRoland McGrathMarcus BrinkmannJuli-Manel Merino Vidal

Juli-Manel Merino Vidal had some problems with his installation efforts. Running 'native-install', the timezone configuration was confusing. It would prompt for "Number:" and he didn't know what to input. Next, when the script ran 'dpkg' twice, it would hang during the second invocation. Pontus Lidman explained, "I had exactly this problem when I had created the HURD partition with a too recent version of mke2fs, from e2fsprogs 1.15. After downgrading to 1.12, it worked. If you use 1.15 you _must_ downgrade because there will be a lot of other problems too otherwise."

Juli-Manel tried this and reported complete success, but Daniel Burrows was under the impression that downgrading was no longer necessary. He said, "I just reinstalled the Hurd last night and the ext2 filesystem (created with e2fsprogs 1.15) doesn't seem to have any problems..I even rebuilt gnumach natively without any problems (after giving up on the cross-compile option :-) ). I also seem to remember a post to this list about the Hurd now being compatible with the newest Linux e2fs. Is my Hurd system about to go down in flames because of filesystem incompatabilities? :-P"

Roland McGrath replied:

I did make such changes and thought them to be correct, but had not tested them at all. You are the guinea pig, and it appears that you lived! If you did things like native builds without your filesystem going down in flames, then it is probably not too likely to go down in flames due to the new changes.

The new ext2fs format changes are not really much change from the perspective of the kernel/filesystem (a little more for e2fsck). The new mke2fs doesn't turn on the dir_prealloc_blocks feature, so you have not exercised that part of the changed code. Probably the only thing exercised is the sparse_super support, and that is really nothing but ext2fs not going out of its way to check and complain about something.

Marcus Brinkmann added, "my next upload will have the fixes. I want some other things to go in the package, too, though, so I am not uploading right now. (But I will upload next week no matter what)."


6. ShadowFS
 Archive Link: "ShadowFS"
People: Marcus BrinkmannMichael Bacarella

Michael Bacarella had heard that shadowfs was used to justify Hurd features that might otherwise be bad; he'd also heard that shadowfs didn't exist yet, and asked for an explanation.

Marcus Brinkmann said he would add a section in the FAQ about shadowfs, and explained, "shadowfs is a concept for yet another translator, which will allow to "mount" several file systems on top of each other, transparently. So, if /dev/hd1s1 contains a file foo, /dev/hd1s2 contains a file bar, both files will be seen in the same directory (the root directory of the common "mount" point). Several options will allow to fine tune the behaviour (which partition will be written to for which files etc)."

Regarding Hurd features that might be justified by it, he said, "Na, we don't use this _too_ often. One thing we explain with shadowfs is the lack of a real /usr on the Hurd. At other points we mention shadowfs when we feel that shadwfs could be useful in such a situation."

Regarding why shadowfs didn't exist yet, Marcus said, "the current development focusses on stabilization and bug fixing. There are other things we urgently need which probably have a higher priority. However, every developer works on what he feels is most important right now, and shadowfs just seems to not be on the top of the list of anybody."







We Hope You Enjoy Hurd Traffic

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.