Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Hurd Traffic #108 For 17�Sep�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. Compiling Jed

3�Sep�2001�-�9�Sep�2001 (7 posts) Archive Link: "compiling under hurd"

People: Roland McGrath,�Stefan Skoglund,�Diego Roversi

Diego Roversi had been trying to compile Jed and wanted to properly conditionalise his patch to send to the author. Roland McGrath said that one rarely appropriate to use #ifdef HURD (or some such). Diego went on to explain the problem in more detail to which Roland replied: "GNU libc has the pty.h header and the openpty function on both Linux and Hurd. Programs should use that" . Stefan Skoglund finished up this thread saying "The application should use openpty directly. If that is absent, then the program should contain an replacement " .

2. Xdm's Shared Libs

8�Sep�2001�-�10�Sep�2001 (7 posts) Archive Link: "xdm problems"

People: Marcus Brinkmann

When attempting to run xdm (from the hurd-F3-main CD) Daniel Lichtenberger found that it uses the library, which he did not have and, which he did have, but xdm failed to find it. Daniel provided extra information, including something about Marcus Brinkmann replied that is a Linuxism and not used with the Hurd. Marcus continued:

The real solution is to use DT_RUNPATH (not RPATH!) when linking the executable, but this will have to wait for the next major binutils version. The reason it works for you is thta you have LD_LIBRARY_PATH set, I would guess (like in /etc/profile)

The reason it doesn't work with xdm is that this program ignores the LD_LIBRARY_PATH env variable for security reasons. You can configure this, though. [] Somewhere in /etc/X11/xdm you can tell it to not ignore the value, or even set it to some fixed value.

The problem with libXdmGreet (which is dlopen'ed at run time) seems unresolved.

3. Naming The System

8�Sep�2001 (8 posts) Archive Link: "Debian GNU or Debian GNU/Hurd?"

People: Evandro Giovanini,�Marcus Brinkmann

There was a bit of discussion about the name of this project/system (i.e. "Shouldn't Debian GNU/Hurd be called Debian GNU?" ), the argument being that the Hurd is part of GNU and GNU is the operating system.

There were other views expressing the need to distinguish ourselves from GNU/Linux.

Somewhat tongue-in-cheek, Marcus finished off this recurring topic (for now) with "Of course, it's all wrong anyway. It should be "Debian GNU/the Hurd" at the very least" .

4. Supporting The Hurd's Features

9�Sep�2001�-�12�Sep�2001 (11 posts) Archive Link: "support for translators in tar"

Topics: FS: ext2, POSIX

People: Marcus Brinkmann,�Thomas Bushnell,�Paul Eggert,�Kalle Niemitalo

This is this week's most interesting and forward-looking thread contributed to by many of the Hurd developers old and new (even Miles Bader!).

For a long time now, the Hurd developers have been expounding on the marvellous new features that that Hurd provides. The problem being that there are not any programs to take advantage of these features.

This week, Marcus attempts to address that problem by spurring development for support of translators in two of the most obvious targets: tar and ls.

For tar, Marcus had in mind the ability to store the translator rather than read through it (much like storing a symlink instead of the (dereferenced) file to which it points):

I want to tackle the issue of support for translators as used in the Hurd by tar. This is important for installation tar files (/dev/ nodes), for example.

For the tar maintainer: The Hurd allows to attach programs to filesystem nodes, those programs service all filesystem accesses (inkl. stat()!). Such running servers are active translators, and mostly transparent to the user. We have GNU extensions in the C library to detect them, though (but we need _GNU_SOURCE).

The servers can be started transparently from passive translators which is a command line string stored in a block of the filesystem and associated with an inode. This command line string is used to start up the actuve translators.

It is those passive translators that should be stored and restored by tar on request.

Some properties of passive translators (aka translators from now on) are shared by symlinks. Both are stored as a string connected to an inode. Both can be dereferenced or not. In fact, symlinks are implemented as special translators in the most general case (for efficiency, filesystem servers can use native symlink support if they want). A symlink is by definition a "/hurd/symlink_TARGET/index.html" translator. The program /hurd/symlink exists and is a translator that provides the expected functionality (of course, this program is not regularly used, and POSIX programs see the symlink as defined by POSIX).

Now to tar. Of course, reading and writing translators is a GNU extension. All calls necessary to do this are part of the C library, so it is easy to add the support (autoconf-wise). I expect that the archive management code is mostly the same between long symlinks and translators.

The default for symlinks is to store them, dereferencing is possible with -h (--dereference). For translators, I think the opposite should be true. Users expect translators to be transparent to normal applications. For example, mount points are also translators, and I expect tar to not store the mount point settings, but the data within.

The check for a translator should be done before any other check, to avoid starting up the server unnecessarily (any normal file i/o on the node, even a stat(), starts up the server). There is one complication. Symlinks, device files, fifos and similar are also implemented as translators. However, I'd expect that a symlink together with the --do-not-dereference-translators option will not store a /hurd/symlink translator, but a symlink. So, the translator handling code will recognize the couple of special translators and coerce them into archive entries compatible to traditional Unix systems.

I write all this to make sure the above is what everybody wants, and in the hope to get some pointers into the relevant parts of the tar code. Of course, if the tar people (Paul?) want to do the changes, I am happy to just assist with the Hurd specific parts and testing. The reason I am not just diving into the source is that the details of tar are quite complicated (format versioning etc), and I am sure that I would spent a lot of time just figuring out where to put the code.

Thomas Bushnell thought that the default mode should be to dereference translators and he went on to say "For the special --do-not-dereference-translators mode, you want basically exactly the same thing for the lookup, except use O_NOTRANS. Then you have to check to see if there is a translator, and if there is, see if it's one of the special well-known translators (and turn them into the appropriate standard special archive entry type)."

Paul Eggert thought that tar should do something similar to ls, as in "ls -l", and asked about the switch to do this for translators. He pointed Marcus to the latest experimental tar ( but warned: "The tar code, to put it politely, is a mess that nobody has had time to clean up. Feel free to dive in, but bring a wetsuit.... "

Unfortunately, ls does not currently support --do-not-dereference-translators either and Kalle Niemitalo added the following about ls and tar:

There has been a lot of talk about extending 'ls' to display the Hurd's fourth rwx permission set. When someone eventually does that, (s)he could also add an option for showing passive translators. That would be more convenient than a separate 'showtrans' program, I think. The output could then also obey the '--quoting-style' option.

The tar format should be extended to support the following data for each file, in addition to what it stores already:

  1. Passive translator:
    • Usage: Command line for a program that the parent filesystem starts when a process looks up the file.
    • Type: List of strings. The strings cannot contain null characters.
    • Frequency: Most files haven't got passive translators.
    • Format: The RPC interfaces and ext2fs (I don't know about ufs) keep the passive translator in argz format (see the glibc manual) so it could be easiest to use that format in the tar file too. The ext2fs format restricts the argz to the filesystem block length minus two bytes, but I don't think tar should inherit that limitation.
    • Default: When extracting a non-Hurd archive, don't set a translator except implicitly via mknod or symlink.
    • API: There is S_IPTRANS for mode_t, but I think that's a bit late since a stat already uses the translator. 'showtrans' gets a Mach port to the file with file_name_lookup, reads the passive-translator argz with file_get_translator, and closes the port with mach_port_deallocate. 'settrans' uses file_set_translator in a similar way.
  2. Fourth rwx set:
    • Usage: Read, Write and Execute permissions for processes that don't have any UIDs at all. There is also a bit that says whether the fourth set is active. If it is not active, then the "other" set is used instead. Legacy programs that set permissions are expected to store 0 in the activity bit, which currently means "not active". Some later version of the Hurd may change 0 to mean "active", so that UIDless processes don't get any permissions by default (since the rwx bits are also 000).
    • Type: 3+1 bits.
    • Frequency: In principle, all files have these bits. However, they will often be all zero.
    • Format: If the bits are zero, I think they needn't be saved. The possible future inversion of the activity bit could corrupt permissions of old tar files. I think it is best to only design the format for now and not actually save nonzero values until we know for sure whether the bit will be inverted.
    • Default: Zero. If it's good enough for legacy programs, it's good enough for legacy archives.
    • API: These mode_t bits can be read with stat and changed with chmod. Constants: S_IUSEUNK, S_IUNKNOWN, S_IUNKSHIFT. See <bits/stat.h> for details.
  3. Author ID:
    • Usage: Another UID. Doesn't affect any permissions. The owner or root can store any value here.
    • Type: uid_t, 32 bits.
    • Frequency: All files have an author ID, but it is normally the same as the owner UID.
    • Format: I suppose tar could store both the number and the name, like with UID and GID.
    • Default: When extracting a non-Hurd archive, don't set the author ID; let the file system choose the default. (FIXME: Is this reasonable if 'tar' then does a chown?)
    • API: To read the author ID, use stat and see st_author. To change it, get a Mach port to the file and call file_chauthor.

Paul Eggert finished for now suggesting that it made more sense to work on "ls" before "tar" since it would be quicker to develop. Having read the next POSIX standard for tar, Paul noted that there was room for translator support, although there were other issues of which he did not particularly approve.

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.