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 #96 For 27 Jun 2001

Editor: Zack Brown

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. Supporting Netgear FA311
10 Jun 2001 - 18 Jun 2001 (3 posts) Archive Link: "integrating a new network driver"
Summary By Paul Emsley
People: Marcus BrinkmannPaul Emsley

Ulrich Eckhardt wanted to integrate support for his Netgear FA311 using the Linux 2.2 drivers in mach and asked for general advice. Marcus Brinkmann replied that he "should look at how the driver is enabled via configure (--enable-something). If you want to use [the driver], it is a good idea to integrate it in gnumach with minimal effort and send us a patch if it isn't too ugly. oskit-mach already has 2.2. drivers I think, maybe even for your card. "

(ed. [Paul Emsley] It does not, as far as I could see.)

Ulrich has yet to report back.


2. Package Maintainers Should Use GNU Autotools
16 Jun 2001 - 17 Jun 2001 (3 posts) Archive Link: "busybox on the Hurd"
Summary By Paul Emsley
Topics: POSIX
People: Roland McGrathMarcus BrinkmannGlenn McGrath

Glenn McGrath wanted to use autotools to help build busybox so that they would be easier to build uing GNU/Hurd and had been discussing this with the maintainers.

Roland McGrath looked at the discussion and said "It sounds like they just have no clue about using autoconf properly." . Marcus Brinkmann read it too and said:

This discussion does not show that they have properly considered autoconf.

There are two things to note here. First, you can use autoconf for all porting issues and still use whatever mechanism you want to use to select different components. Although selecting the components can be done using autoconf in a nice way, if that way is not what they want, they can use whatever other method and make autoconf to look up the configuration there.

The other thing is that they are not realizing what autoconf would give them. They seem to favor a system based configuration system. "Select your OS, [ ] Linux, [ ] BSD, ..." etc. If you are down at this level of elegance, you don't need to ask at all, you can just use the systems preprocessor symbols __linux__, __BSD__ etc (if you are a bit careful), or just use config.guess, which does all the work for you.

In my experience porting literally hundred of software packages to the Hurd, porting packages which are based on the system rather than the individual feature components has always been very, very painful. It takes me about ten times more time and effort to get it right on such systems, because I have a lot of more work to do than on autoconf/feature based configuration systems. There are several reasons why:

Sometimes those systems are written in a mixture of system discrimination and feature discrimination, where the features are enabled in a system specific file. For example, a file would enable SHARED_MEMORY, and SHARED_MEMORY would be checked if to use shared memory on this system. But also, __linux__ is used freely in the code to check for linux wthout giving it a feature symbol.

This approach has two problems:

  1. First, when I port the package, I have to learn a wholly new configuration system. I may misunderstand what the symbols are meant to define, and documentation is most often lacking (exim being a nice exception to the rule, but take a look at XFree86!). I also have to check all explicit uses of __linux__/__BSD__ and other similar systems, because most of the time the authors didn't get it right, and enabled features on Linux only which are coming from GLIBC and so on. This is a lot of extra work for me.
  2. The second problem is that it is harder to maintain such software. I have rarely seen an author who will maintain the Hurd port for me on such configuration systems, so with every couple of releases, there are some new symbols or places where __linux__ is used instead __GLIBC__, which I have to port again. I have to find out which new feature macros are defined (and of course not enabled on the Hurd configuration), and I have to check for new places where __linux__ is used where it is not appropriate. Porting suddenly doesn't become a no-brainer anymore, because every new release has to be checked and maintained.

On such systems, it can take several months to a year to get a version that works without changes, and this is an unstable situation, too (the next version might be broken again).

Because these systems often require external, system-dependant input, the Debian packaging scripts have to be modified. Compiling it for different systems requires different commands. You loose automatization.

When doing the port, I don't know how the author would like to make the discrimination I am looking for. It is likely that I will write a patch that might not be acceptable, because I don't know the policies of the authors wrt configuration options (when to introduce a new feature? When to hack with __linux__?).

When my patch is incorporated, but modified along that way, because it was not acceptable as I wrote it, it happens occasionally that the result will not work because of subtle differences on the system I port to the author didn't know about.

What is my experience with autoconf based systems?

Most of them, I would say, between 75-90 per cent, work out of the box. The critical differences are already checked for by autoconf automatically, and the compilation runs fine. When a feature is used which is not checked for, it is easy to add a new check, and use it in the code. I know what the author expects, because autoconf is used in a standard way, and I know that my change expresses my need accurately, because it is feature based, and the feature which is checked for is explicit in the patch.

One person expresses in the thread that busybox will only compile and run on GNU/Linux. This narrow minded-ness can be taken care of by autoconf. If you use autoconf properly, busybox can run and compile on *every* posixish system. I hope he didn't mean that they are not interested in being able to use busybox only on GNU/Linux. It would be sad if the Debian installer team locked itself in a one-system only software, which had to be forked to get it working on GNU/Hurd.


3. New CD Packages, Exim And ae; Being In testing
17 Jun 2001 - 19 Jun 2001 (6 posts) Archive Link: "ae & exim"
Summary By Paul Emsley
People: Jeff BaileyPhilip CharlesRobert Bihlmeyer

Philip Charles wanted updated versions of ae and exim for the F3 CDs. Jeff Bailey said "I'll recompile ae, and check what's up with exim. Mostly, I've been trying to make you have a 3rd CD. Over 40 uploads in the last day. ;) "

"That's the kind of problem I like. You can keep the other kinds," said Philip.

Jeff uploaded ae 962-30.01 and elswhere under the topic Exim said that he uploaded exim and gave a pointer to a patch.

The topic changed to New CD set (was: Exim) and Robert Bihlmeyer said:

It would be good to avoid e2fsprogs 1.20-2 which is currently in the archive. With it you have to answer yes for every disk when booting.

FWIW, if hurd-i386 were included in the "testing" mechanism, could you easily produce CDs from testing? This would prevent problems like e2fsprog's.

Jeff Bailey replied to this:

I want us in testing for two reasons:

  1. Visibility
  2. So we have a noose around various maintainers necks if they break their packages.

But we need to be compiling 90%+ of the packages succesfully to do this. Without pthreads, and without some arch: proposal to add linux-all, linux-any, we've got a ways to go.


4. Status Of Some Packages
19 Jun 2001 - 20 Jun 2001 (7 posts) Archive Link: "Outstanding patches in the BTS"
Summary By Paul Emsley
People: Neal WalfieldIgor KhavkineNeil WalfieldJeff Bailey

Igor Khavkine wanted an update on the bugs in the BTS (Bug Tracking System) (these being for libsasl7, libgc5, smail, w3m, and bsd-games). Igor said that bsd-games can now be added to the autobuilder and that someone should do NMUs for the others. Jeff Bailey said that he would do the libsasl and libgc5 packages but wait for smail and w3m.

"Now that we have games, we are a real OS, right?" said Neil Walfield.

There was no reply.


5. Use GNU Autoconf For strerror()
20 Jun 2001 - 22 Jun 2001 (2 posts) Archive Link: "anybody still having just sys_errlist?"
Summary By Paul Emsley
People: Marcus BrinkmannRoland McGrath

Marcus Brinkmann was worried that some of his package patches were not general enough:

Are there actually systems which have sys_errlist but not strerror()?

Recently I tend to just change it without providing a wrapper for it in my patches, because that's simplest. But if there are some BSD systems or so which still use sys_errlist exclusively, I should probably not get into the habit.

Roland McGrath replied "It is quite unlikely anyone will fail to have strerror any more. But, it is not a big deal one way or the other, since the way to be totally portable is to include the canonical strerror.c you can find in some random GNU packages and do AC_REPLACE_FUNCS(strerror). "


6. GCC-3.0
20 Jun 2001 - 21 Jun 2001 (9 posts) Archive Link: "GCC-3.0 uploaded to incoming"
Summary By Paul Emsley
People: Douglas HiltonIgor KhavkineRoland McGrathJeff Bailey

Elsewhere (in the thread "Exim") Igor Khavkine and Jeff Bailey discussed gcc-3.0 and the Boehm garbage collector. Now Jeff successfully compiled it an uploaded it. Roland McGrath worried about the current gcc/glibc compatibility and that the linux-2.0.x drivers in gnumach may not be suitable for gcc-3.0.

Douglas Hilton wanted to port gnat to GNU/Hurd. Roland advised him to wait for a unified gcc-3.0.


7. Status Of e2fsprogs
21 Jun 2001 - 22 Jun 2001 (11 posts) Archive Link: "e2fsprogs"
Summary By Paul Emsley
People: Jeff Bailey

Jeff Bailey uploaded the lastest e2fsprogs to incoming. This package fixes the detection problem.







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.