Mach 4 (http://www.cs.utah.edu/projects/flux/mach4/html/) | Hurd Servers (http://www.gnu.org/software/hurd/hurd.html) | Debian Hurd Home (http://www.gnu.org/software/hurd/debian-gnu-hurd.html) | Debian Hurd FAQ (http://www.debian.org/ports/hurd/hurd-faq) | debian-hurd List Archives (http://lists.debian.org/#debian-hurd) | bug-hurd List Archives (http://mail.gnu.org/pipermail/bug-hurd/) | help-hurd List Archive (http://mail.gnu.org/pipermail/help-hurd/) | Hurd Reference Manual (http://www.gnu.org/software/hurd/reference-manual.html) | Hurd Installation Guide (http://pick.sel.cam.ac.uk/~mcv21/hurd.html) | Cross-Compiling GNUMach (http://pages.hotbot.com/sf/igorkh/gnumach-cross.txt) | Hurd Hardware Compatibility Guide (http://www.urbanophile.com/arenn/hacking/hurd/hurd-hardware.html)
Table Of Contents
|1.||3�Sep�2001�-�9�Sep�2001||(7 posts)||Compiling Jed|
|2.||8�Sep�2001�-�10�Sep�2001||(7 posts)||Xdm's Shared Libs|
|3.||8�Sep�2001||(8 posts)||Naming The System|
|4.||9�Sep�2001�-�12�Sep�2001||(11 posts)||Supporting The Hurd's Features|
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 libXdmGreet.so, which he did not have and libXmu.so, which he did have, but xdm failed to find it. Daniel provided extra information, including something about ld.so.conf. Marcus Brinkmann replied that ld.so.conf 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 (ftp://alpha.gnu.org/gnu/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:
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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.