Hurd Traffic #111 For 8 Oct 2001

By Paul Emsley

Mach 4 ( | Hurd Servers ( | Debian Hurd Home ( | Debian Hurd FAQ ( | debian-hurd List Archives ( | bug-hurd List Archives ( | help-hurd List Archive ( | Hurd Reference Manual ( | Hurd Installation Guide ( | Cross-Compiling GNUMach ( | Hurd Hardware Compatibility Guide (

Table Of Contents

1. "And Our Survey Says..."

3 Oct 2001 - 4 Oct 2001 (3 posts) Archive Link: "Age Review and another Hurd webserver"

People: James Morrison

Last week, James Morrison had asked about the ages of debian-hurd hackers. This week, he released the results ( (around 30 people of the 800 or so subscribers answered (the modal age being 20/21)) and put them on his GNU/Hurd-based web server ( .

2. G1 CD Images Available

4 Oct 2001 (3 posts) Archive Link: "G1 CD images"

People: Philip Charles

Philip Charles let us know that the G1 CD images are available from ( and mirrors.

He noted that it is possible to get a working system from only the first disk.

3. What Is To Be Done (Release-wise)?

4 Oct 2001 - 5 Oct 2001 (5 posts) Archive Link: "Will the hurd go into woody ?"

Topics: Apt, POSIX

People: Marcus BrinkmannJames Morrison

In reply to the question of whether or not GNU/Hurd will make it into the woody release, and what is in fact necessary for an official release, Marcus Brinkmann said "[No], I am much more worried about developing the boot floppies and ensuring functionality of the packages than about package counts (for the release)."

Marcus continued with a long explanation of why GNU/Hurd releases should be synchronised with the rest of Debian architectures:

There is a big fat disadvantage, and that is that we share 99.99% of the packages, and it's old Debian tradition to break second package from the time of a release to shortly before the next release. Getting a release together while Debian changes under your feet will be considerably harder than if you just step in measure with the masses.

The other disadvantage is that you have to duplicate the complete release. A release is a lot of work, so much work, that it usually burns at least one person entirely on the way. I would like to avoid that if at all possible and have as much of the common work done by Debian people (both, GNU/Linux and GNU/Hurd) rather than by us alone.

A release comes with many strings attached (for example, it's also a strong commitment on upgradeability, and a commitment for extensive testing cycles and newbie help). I don't want to rule out that we do some sort of intermediate release between woody and woody+1, but I don't see it currently within my sight. It depends on too many factors I can't calculate (ideally, I would break binary compatibility of glibc before we do the first real release, and do it only once. This means we need to get POSIX threads in shape. This is just an example, but it's certainly the thing that bothers me most).

Marcus went on to say that new GNU/Hurd architectures being ready before the next GNU/Linux release are problems to address if/when they happen and that there are other problems to address, such as "do you really want a release which has the Debian GNU/Linux makedev package in the archive? Getting rid of that requires changes in dpkg, apt, dinstall and all other packaging tools out there. And this work has not started yet. In fact, it is not even discussed and decided how to go about it."

It was decided that someone should create a "roadmap", a list of things that need to be done before a release is possible. James Morrison stepped forward as that someone and made a roadmap web page ( .

4. Be Patient With stat Maintainer

5 Oct 2001 - 6 Oct 2001 (4 posts) Archive Link: "Regarding stat and bing patch for HURD"

People: Marcus Brinkmann

Nikunj Dadhania seems to be a little irritated at the maintainer of stat for not applying the patch that he had sent 49 days ago.

Marcus Brinkmann suggested he be patient(!) saying: "if a fix is ignored because the package is currentyl not actively maintained (maintainer has no time etc), another Debian developer can step up and make a non-maintainer release of the package. You can ask here if somebody is willing to do that for stat. However, 49 days is not soo long in the Debian world, I have bug reports filed over a year ago, without having the benefit of an opinion about it by the maintainer ;)"

5. Building OSKit-Mach Documentation

21 Sep 2001 - 2 Oct 2001 (5 posts) Archive Link: "Building OSKit-Mach (texinfo format)"

People: Kevin Kreamer

Kevin Kreamer let us know that the latest version of the Building OSKit-Mach documentation can be found here ( .

6. Tinkering With Mach Header Files

27 Sep 2001 - 29 Sep 2001 (9 posts) Archive Link: "mach_port_t vs task_t (really ipc_space_t) in Mach header files"

People: Marcus BrinkmannRoland McGrathThomas Bushnell

The types of some functions are inconsistent between the .def and .h files. Marcus explains:

I saw that the defs file have nice specific types like ipc_space_t and mach_port_name_t, but the C header files almost all have mach_port_t for them. In the Hurd, we have a typedef for each of these types and keep them in the header. We even use task_t in proc etc.

I am now using mach_port_t in mach.texi everywhere (where it is used in the generated C header file), rather than the more explicit type in the defs file. But maybe we don't want that?

In answer to Marcus' question, Roland replied: "The reason for the types in .defs files is for intran/outtran. I would tend toward using the specific types generally, because that has more of a chance to be mapped source-compatibly in some other RPC system. There are probably a few weird hacks that rely on true port polymorphism. But most of the uses can be described as interface subtyping (e.g. file_t and socket_t are subtypes of io_t)" and Thomas Bushnell gave an instance of such a case: "The auth server, for example, hands ports around, and they are fully generic as far as the auth server sees them, but (generally) io_t as far as the users are concerned."

Marcus replied "as the interface definitions explicitely set the "ctype" to mach_port_t (that's what MiGs makes to put this type in the header). Maybe we should go and change those interface definitions were we prefer the specific types without ctype parameter?"

Roland thought it was probably not a good idea to fiddle with the .defs, for some obscure reason that he couldn't quite remember. After some consideration, Marcus finished off with:

this is indeed true. A simple test shows that this is not straightforward at all. For example, mig does automatically convert mach_port_t into ipc_port_t for a KernelServer in some interfaces, and something related to it (or even something else!) blew my naive attempt at changing the ctype (and even my more sophisticated attempt involving cservertype and cusertype)... might be that a lot of conditionals could rectify this, but as I am not enthusiastic about changing those files either, I guess I have to drop that idea. (Although it is still interesting to know more about this, and to understand why it is done that way).

I stipulate this was done for simplicity, rather than to imply that the view of all users on all these ports should be mach_port_t (although the original Mach docs all use mach_port_t everywhere).

The devil is in the details...

7. Long Hostnames In Heimdal

28 Sep 2001 - 30 Sep 2001 (18 posts) Archive Link: "heimdal on GNU HURD"

Topics: POSIX

People: James MorrisonJacques VidrineThomas BushnellMarcus BrinkmannNeal Walfield

Regular readers of these summaries will know that the Hurd developers have had run-ins (a.k.a. "extensive discussions") with several package developers/maintainers (who don't appreciate adding what they see as unnecessarily complex code to support the Hurd). This week there was another one, with that of Jacques Vidrine, a Heimdal ( developer.

We start with James Morrison saying that he had sent a patch to the Heimdal maintainers. James had written: " This patch removes the need for MAXHOSTNAMELEN by using the function xgethostname by Neal Walfield. Removing MAXHOSTNAMELEN and conditionalizing the use of ARG_MAX, which is not defined on GNU (HURD), allows heimdal to compile on GNU (HURD). xgethostname is not in the patch, but a separate attachment. I but it goes in lib/krb5. In the patch xgethostname is expected to be in lib/krb5 because I have added it to "

Jacques Vidrine objected to the patch because it did not behave like other Unices. This is the crux of the discussion: "Almost all versions of UNIX specify MAXHOSTNAMELEN (see [Stevens UNPv1]). The Hurd probably should, too. IMHO a system that defines neither MAXHOSTNAMELEN nor HOST_NAME_MAX is broken I'm ignoring the fact that HOST_NAME_MAX is one of the many `possibly indeterminate run-time invariant values'. Any system designer that requires use of sysconf() for such basic constants should be drawn-and-quartered :-) . "

Now, of course, this is not what the Hurd developers like to hear. Thomas Bushnell replied:

Note that no system is required to define HOST_NAME_MAX, specifically, if there is no maximum. The situation is just like that for PATH_NAME_MAX.

You are supposed to check for a compile-time constant, which might not be defined. You can check for a run-time constant with sysconf, and on the Hurd it will return -1, indicating the absence of any limit.

If you want the program to be Posix compliant, then you cannot assume that HOST_NAME_MAX is always defined.

The correct thing to do is to use the referenced xgethostname, which calls gethostname in a loop in order to get a big enough buffer.

Marcus chipped in with:

If you use path_conf, you will notice that it might return -1, as it does on the Hurd, indicating that there is no limit on the filesystem denoted by the path.

We not only require you to use sysconf, we also let sysconf return -1, to indicate that there is no fixed limit. There is a good reason we do so. First, there really is no limit, so saying that there is a fixed limit although there really is none is simply wrong.

So why is there no limit? Because we do not like to impose arbitrary limits on the users. Arbitrary limits always turn out to be too small at some time, and they are a hard limit for scaleability.

There is a deeper reason why on the Hurd defining a limit nevertheless would be wrong. The Hurd is a user extensible system. This means that any component of the Hurd system can be ignored/overwritten/replaced by the *users* of the system without restriction and without compromising security. But to make it easier for users to be able to continue the usage of the default libraries and system components, we write those components in the most flexible way, setting as little constraints as possible. One such constraint is the length on hostnames.

Of course, people who have excessive needs can always patch and compile their own copy of the applications and run them. However, we would be happy to have the flexibility in the official versions of the software already. We would like to say that the Hurd has no limit on the length of the hostnames and the applications we compile for it don't impose one as well, rather than saying that we don't have any limits, but heimdal imposes its own limit constraining the user.

We have already fixed a lot of such ignorant applications, and usually the authors and maintainers are happy to accept the patches. So many programs already support arbitrarty long hostnames on the Hurd.

However, as you are already aware of that heimdal is not a POSIX compliant application while the Hurd is a POSIX compliant operating system, and you prefer us to be drawn-and-quartered rather than fixing heimdal, I am not sure what I can say to convince you otherwise, beside trying to explain to you why we don't define an arbitrary limit. I hope you agree after the above explanation that there is really a value in not defining a limit and fixing the applications that can't deal with the lack of it.

There was some discussion about what the standard says for hostnames, Marcus saying what he had said before: that the Single UNIX specification had been in error. "This error was taken over to POSIX draft 6 (from the Austin group), which also said that hostnames are limited to 255 characters. This was fixed in draft 7 by removing this limit and making HOST_NAME_MAX one of the possible undefined constants, as rightly was pointed out. Obviously the Austin group did not think that any arbitrary limit was desireable. "

Nevertheless, Jacques continues with his original thinking: " I think it is shameful, however, that the Hurd will not define MAXHOSTNAMELEN or even HOST_NAME_MAX: this seems to be biting the thumb at portability. POSIX is not UNIX :-) "

"GNU's not UNIX either" , retorted Marcus. "Blame the person who designed gethostname() in the first place" .

And this again displayed the difference in opinion, Jacques saying that he didn't want to blame them because "the interface has worked quite well in the real world, and indeed POSIX has taken the oppurtuntity to standardize that interface. "

Thomas Bushnell jumped into the argument asking "Do you really think that there is a serious cost in using xgethostname within Heimdal?" Jacques replied "No, I don't -- I just think it is a bug" , to which Thomas asked rhetorically "It's a bug to correctly support long hostnames?"

Getting tired of arguing, Jacques sighed and said "regardless of these academic arguments, I guess we'll have to implement something like xgethostname just for GNU/Hurd, since there doesn't seem to be any support here for following the rest of the UNIX world."

The conversation turned to the actual occurrences and utility of long hostnames, Marcus lightening the tone somewhat with:

And Thomas doesn't live in Wales, UK, where we notice:

(that's the name of a village)

To which Thomas replied:

I saw this and said "is that real?" So I typed (well, cut-and-pasted):


After a brief pause, the following output came. Note carefully the first line:

 ( 56 data bytes
 64 bytes from icmp_seq=0 ttl=40 time=174.3 ms
 64 bytes from icmp_seq=1 ttl=40 time=172.1 ms
 64 bytes from icmp_seq=2 ttl=40 time=171.9 ms
 64 bytes from icmp_seq=3 ttl=40 time=180.6 ms
 64 bytes from icmp_seq=4 ttl=40 time=171.3 ms

     ping statistics ---
 5 packets transmitted, 5 packets received, 0% packet loss
 round-trip min/avg/max = 171.3/174.0/180.6 ms

I take it this should prove the point. Someone at "ping central" got it wrong.

8. libstore.h Installed Twice?

2 Oct 2001 (2 posts) Archive Link: "building libstore replaces /include/hurd/store.h"

People: Kevin Kreamer

Kevin Kreamer had a problem when building the Hurd: "the $(MAKE) invoked in libstore/ replaces /include/hurd/store.h."

Maurizio Borian had seen this too and suggested that the installation of store.h should be removed from the libstore Makefile because it it already done from the Makefile in the main src directory.

There was no reply.

9. cpu.h Gets Accidently Deleted

2 Oct 2001 (3 posts) Archive Link: "oskit-mach as of today, oskit-20010214, and missing cpus.h"

People: Daniel WagnerGordon Matzigkeit

Gordon Matzigkeit was getting compilation errors:

kern/lock.h:37: cpus.h: No such file or directory

Daniel Wagner replied that a make clean will delete it along with all the header files in the build directory. Gordon took Daniel's Makefile and suggested a patch.

There was no reply.

10. GNU Mach Documentation

3 Oct 2001 (4 posts) Archive Link: "Documentation committed"

People: Marcus BrinkmannThomas Bushnell

Marcus Brinkmann has been working on Mach documentation recently. He posted: "I feel now reasonable good with the documentation that I committed it to the CVS, to make maintenance easier. In fact I also added it to the Debian package, and added the doc and debian dir to the dist target. I think the manual is already pretty damn useful, but it's also far from perfect, so patches are always welcome of course. I am still waiting on a word from CMU wrt a license for the books, but for example, there is a section about the history of Mach missing, and you don't need to know any coding to write that." Marcus noted that the documentation, by default, is not built.

Thomas Bushnell said that he thought that the GNU coding standard say that documentation should be built by default and that an info version should come prebuilt.

Marcus said that this "bug" is also shared by the Hurd - and should be fixed before release.







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.