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

Hurd Traffic #65 For 1 Nov 2000

Editor: Zack Brown

By Paul Emsley  and  Zack Brown

Mach 4 | Hurd Servers | Debian Hurd Home | Debian Hurd FAQ | Debian Hurd Mailing List | Hurd Reference Manual | Hurd Installation Guide | Cross-Compiling GNUMach | Hurd Hardware Compatibility Guide

Table Of Contents


Want to help write KC Debian Hurd? See the KC Authorship page the KC Debian Hurd homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.


1. Out Of Date Documentation On Partition Naming Scheme
14 Oct 2000 - 24 Oct 2000 (22 posts) Archive Link: "bootstrap: panic: ... invalid IO size"
Summary By Zack Brown
People: Robert BihlmeyerMarc Singer

In the course of discussion, Robert Bihlmeyer complained about the partition naming system, saying, "I think that the current naming system is confusing and incoherent. Why are ide disks on a fixed position, while scsi disks are always in a contiguous block sd0 to sdN?" Marc Singer replied, "According to the documentation, such is not the case." Robert asked for a pointer to those docs, and Marc gave, quoting:

Hurd uses different partition names to Linux, and this can be confusing. IDE hard disks are numbered in order, beginning from hd0. Note that the second IDE drive will always be hd1, regardless of whether it is a slave or a second master. SCSI drives are also numbered in the same way, in absolute order (so not necessarily the drive ID): they will always be sd0, sd1, and so on regardless of whether the two drives are SCSI id 4 and 5 or whatever."

He added, "This is, in fact, not the case. The first physical disk on my machine is numbered similarly as it is on Linux, according to the controller and the master/slave status of that device. My only IDE drive is a master on the second controller and it is hd2." Robert replied, "You are right. <URL:>, for example, gives the right scheme."


2. Problems With X And The Upstream Maintainer
20 Oct 2000 - 25 Oct 2000 (16 posts) Archive Link: "Plans for X"
Summary By Zack Brown
People: Steve BowmanMarcus Brinkmann

Steve Bowman asked:

Marcus, so what _is_ the plan now with X on hurd. A few days ago, I saw a bit of discussion between you and Branden on debian-x that didn't sound too promising. I did a bit of digging at his home on samosa and what I saw confirmed my original idea of his plan - that the 3.3.6 servers will continue to support the old cards. However, I also see that support for new cards is already being stripped. I didn't do a very exhaustive search, but his comment about 3.3.6 as known on potato being dead seems very true for the 3.3.6 packages already set to go into woody when 4.x is rolled into woody.

Are you still negotiating for 3.3.6 with patches for hurd to stay, maybe looking at a (temporary) fork, planning to rework your patches for 4.x, or do you have other alternatives? Any chance of getting cooperation from upstream to write hurd support in upstream or do they expect patches from the hurd community to get the porting done?

Marcus Brinkmann replied that the upstream maintainer didn't want patches for Xfree86 3.3.6 because he was already focusing on 4.x; but Marcus didn't have time to do that kind of patch porting, and said (Ccing Branden) he'd have no choice but to fork the 3.3.6 tree, if the patches couldn't be incorporated. A few days later Marcus replied to himself (not Ccing Branden), saying that actually it didn't look too difficult to port the patches to 4.x; apparently no one had bothered to look at what would be involved, but had just rejected the approach outright. He added, "I will follow up with real patches. If somebody has the guts to help out, I can make preliminary patches available soon, but only if you really want to debug things. Otherwise just wait for the packages to become available and stick with XFree 3.3.6 for now." Steve was game to work on it, and they went back and forth with patches and hackery.


3. Projects For The Hurd
23 Oct 2000 - 26 Oct 2000 (9 posts) Archive Link: "Looking for a project"
Summary By Zack Brown
Topics: GGI
People: Farid HajjiMarcus BrinkmannChris SilvaRobert Bihlmeyer

Ali Ijaz Sheikh wanted to do some Hurd work to satisfy a school requirement, and asked what projects were available. Farid Hajji suggested helping port the Debian Hurd to the GPLed L4. He explained, "Mach is really an outdated microkernel that is too heavy-weight and not very performent. L4 on the contrary is much smaller and extremely efficient." Chris Silva was interested in this, and Marcus Brinkmann added, "But hasn't anything to do with the Hurd in particular, of course. Any work on this must be Debian-all... (not that I agree with the need for this). BTW, there is also debian-bsd, so..."

There was also some discussion of Hurd-related projects that might be interesting to take up. Farid listed in his original reply:

Besides the ports of user-level ppp and X11 which are being worked on right now, help would be appreciated in the oskit-mach branch.

Personally, I'd also welcome the port of some FreeBSD features to the way too Linux-centric Debian Hurd distribution. I'm thinking here of FreeBSD's excellent /usr/ports system, but probably also of its release management structure and even maybe its libc.

Another project may be adding binary compatibility mode to the Hurd. Just like the "linuxulator" under FreeBSD.

Robert Bihlmeyer replied to Ali, saying that enabling filesystems larger than 1G would be a great thing to have, and Marcus replied that it would make a good school project. Robert and Marcus also agreed that more work on GGI (or some other graphics system) would be good. Elsewhere, Marcus also said that pthreads, SMP support, features for distributed systems, nifty translators, and a whole slew of things he couldn't think of, would all be great to have for the Hurd.


4. XFree86 4.0.1 Success!
23 Oct 2000 - 27 Oct 2000 (20 posts) Archive Link: "XFree86 4.0.1 works!"
Summary By Zack Brown
People: Marcus Brinkmann

Marcus Brinkmann announced that XFree86 4.0.1 worked under the Hurd. He explained:

That was easier than I expected. A simple counter increment was missing from the mouse code, so it didn't receive any events. Now it works.

In fact, it works excellent. XFree86 4.0.1 is just not supporting my graphic card, so I can only run 4bit color depth in 800x600 ;) Also, my graphic problems were actually no problems: In depth8, you get only 320x200 (and only half the screen was used, I don't know if this is correct. Anyway, with depth 4 I get full screen).

I posted the patch to, I don't know if this is publicly available, so I put up a copy at

The debian packaging will follow later, don't press it, I need to give Branden some time to respond to my latets efforts. You also need a small fix in the mouse server, which I will add to the next Hurd Debian package soon to come.

There are a couple of problems, here is my current list:

  1. pflocal gets a load of threads (about 1700 after a couple of minutes using X). This doesn't seem to be harmful though. Killing pflocal between X sessions help. Does killing pflocal during an X session kill X?
  2. mouse translator get's slow after a while, so mouse movement lags behind. Killing the mouse translator helps. Does killing mouse during an X session disturb X?
  3. xdm deletes LD_LIBRARY_PATH from the environment, which means that it can't start other X processes. Setting the following in /etc/X11/xdm-config works around that, but might be a security risk(?): DisplayManager.exportList: LD_LIBRARY_PATH Could also be fixed with rpath, which conflicts with Debian policy.
  4. kbd translator returns Interrupted System Call at open(). I can't reproduce this seperate from the Xserver, so this is a weird problem. Trying several times usually leads to success.
  5. pflocal doesn't release the socket, and X thinks another server is already running. Sometimes killing pflocal helps, sometimes not (and in the cases it doesn't, I really wonder what's the culprit).

So, as you can see, X and Hurd servers have some problems to cooperate nicely. This is a big chance for you (yes, YOU) to actually get the hand dirty with a debugger and debug some *interesting* Hurd translator bugs. Don't underestimate the challenge to track down and debug those bugs, and the fame will also be yours if you do it!

There followed a lengthy technical discussion, in which a number of folks had problems with the patches, and various improvements were suggested.


24 Oct 2000 (4 posts) Archive Link: "MAXHOSTNAMLEN"
Summary By Paul Emsley
Topics: POSIX
People: Martin StenzelIgor KhavkineMarcus BrinkmannRobert Bihlmeyer

Martin Stenzel wondered:

whether the values for




are correct for the Hurd.

To which Robert Bihlmeyer and Igor Khavkine replied that it was part of the GNU philosophy to remove such arbitrary limits and so these macros were not defined in Hurd. Igor Khavkine added "Everybody should be able to come up with a few misguided limits from the past. Think: 8+3 character filenames, 640K, two-digit year." The right thing to do, he explained, was to patch the code which needed these macros.

Marcus Brinkmann suggested using:


Posixly correct software should in this case with pathconf("...", _PC_PATH_MAX) which will return -1 on the Hurd, which means no limit, and you have to handle any length memory can take (malloc/realloc/loop).


Any length can occure, and you should check for ENAMETOOLONG and realloc a larger buffer. See inetutils source gethostname implementation, or other places which do it correct.


6. Hurd Boot Floppies Available
26 Oct 2000 (1 post) Archive Link: "Hurd boot-floppies source"
Summary By Zack Brown
People: Philip Charles

Philip Charles announced, "A small file, hurd-floppies.tar.bz2, can be downloaded from the bottom of the opening page of which contains the changes to boot-floppies 2.2.16. This converts the standard boot-floppies to 2.2.16-hurd-C. Just copy the amended files into boot-floppies." There was no reply.







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.