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 #13 For 31 Aug 1999

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
-- Linus Torvalds, 1991

Table Of Contents


Sorry about the delay, there have been server problems at this end. Also my little laptop finally gave out. It was crashing whenever I touched it, pretty much, and the screen was getting gradually dimmer. But I'm now on a brand new Fujitsu Lifebook courtesy of Linuxcare. This should hopefully take a lot of the uncertainty out of KT/KC.

Mailing List Stats For This Week

We looked at 84 posts in 233K.

There were 25 different contributors. 16 posted more than once. 1 posted last week too.

The top posters of the week were:

1. Master Boot Record

11 Aug 1999 - 24 Aug 1999 (12 posts) Archive Link: "Success on installing Hurd"

Topics: Bootloaders, FS: ext2

People: Kalle Olavi NiemitaloRoland McGrathJim FranklinMarcus Brinkmann

Nuno Emanuel F. Carvalho successfully installed the Hurd using the Debian package method (as opposed to the tarball method), but got an error on the initial reboot, subsequent to running 'cross-install' (later boots were error-free).

The error was:

  [ ... ]
  Partition check (DOS partitions):
      hd0: hd0s1 hd0s2 hd0s3 hd0s4 <hd0s5 hd0s6 hd0s7 hd0s8>
  com0: at atbus0, port=3f8, spl=6, pic=4. (DOS COM1)
  com1: at atbus1, port=2f8, spl=6, pic=3. (DOS COM2)
  hd04: bad access: block=28, count=2, blockend=30, nr_sects
  end_request: I/O error, dev 03:04, sector 28
 [ ... ]

The source of the error went unresolved, but Nuno had several questions. One of them was whether GRUB could only be installed on the MBR, or if it could be installed elsewhere, such as on the Hurd's own partitions. Kalle Olavi Niemitalo said installing it to the Hurd's own partition should work, and added, "I have GRUB and kernels in hd0s1 which is a 64-megabyte ext2 partition. I use Neil Turton's enhanced MBR, from the Debian "mbr" package." Nuno replied that he had searched for the 'mbr' package in Contents-hurd-i386.gz and hadn't found it. Kalle replied that he should look in binary-i386/base. He added, "The i386 vs. hurd-i386 difference doesn't matter since the code gets loaded before the operating system. "dpkg --force-architecture" should do the job." He added that after installing the package, /boot/mbr.b had to be installed in the MBR, but that he didn't know how to do it.

Marcus Brinkmann replied, saying that

dd if=/boot/mbr.b of=$disk bs=444 count=1

would do the trick.

Jim Franklin asked what the 'mbr' package's benefits were. Roland McGrath said he didn't see any advantage over simply installing GRUB to the MBR, and Kalle added, "The installation program of a certain non-free OS overwrites the MBR, so recovery is easier if GRUB isn't there."

2. Low Memory Systems

14 Aug 1999 - 23 Aug 1999 (10 posts) Archive Link: "memory_object_data_request failed"

People: Simon HolgateMark Kettenis

Simon Holgate followed the Easy Guide on his 486 with 8M ram, but during 'native-install' he got the following errors:

memory_object_data_request(0x0,0x0,0x69000,0x1000,0x1) failed,
(default pager): dropping data_request because of previous paging errors
(default pager): dropping data_request because of previous paging errors
(default pager): dropping data_request because of previous paging errors
memory_object_data_request(0x0,0x0,0x69000,0x1000,0x1) failed, 268435459
memory_object_data_request(0x0,0x0,0x69000,0x1000,0x1) failed, 268435459

Mark Kettenis said it looked like he was running out of memory, which came as no surprise if Simon was only using 8M ram. He recommended using some swap. Simon replied that he'd tried that, but got the errors before he could enable swap. Mark recommended adding the lines

# default pager                                                                                                  
/dev/hd1s1 $(add-paging-file) $(default-pager)

to /boot/servers.boot, though he felt that 8M was just too little for the Hurd. Simon reported success, and added, "In case any one else is interested the swap has to be the old style liunx swap (-v0) not the new style (-v1)."

Mark replied that the new style would probably work with a recent Hurd, and that the tarball Simon used probably didn't have a new enough Hurd on it.

3. Syslogd

19 Aug 1999 - 23 Aug 1999 (4 posts) Archive Link: "Re: new inetutils package with better syslogd"

People: Roland McGrathMarcus Brinkmann

Responding to Marcus Brinkmann's Issue #11, Section #4  (7 Aug 1999: Inetutils Update) , Roland McGrath was happy about the syslog upgrade, and felt that having a single syslogd implementation as a separate package was the way to go.

Regarding kernel logging, Roland replied:

There is not much that needs to be done in the syslog end. The plan is to provide a /dev/kmsg device that behaves essentially just like /proc/kmsg on Linux. The existing 'klogd' arrangement used on Linux should work fine using this just as it does /proc/kmsg.

Now, there is in fact no /dev/kmsg device available as yet. The kernel support is there and (I think) works; it's turned on by --enable-kmsg, and that should be in the default package version if it's not already. The missing piece is a Hurd translator for such "stream" devices (the 'kmsg' device behaves essentially like a serial port where the kernel's messages are arriving as a stream of bytes on the input queue). OKUJI began working on one (called streamdev) a while back, and it is not at all hard to get the basic functionality for that working. If someone picks this up and gets it working, we'll put it into the Hurd sources.

Finally, regarding 'syslogifying' the Hurd, Roland gave a fascinating explanation:

The main issue here is making sure we use a highly robust way of getting the messages out without blocking, both early during boot-up or any time things get badly frotzed.

syslog (openlog) has LOG_PERROR and LOG_CONS to get messages out when syslogd is not running, and that suffices on Unix writing to the console never blocks undesireably unless the whole system is scrod.

In the Hurd, it's a different story. During boot, the terminal server is not yet running at all. Also, At any time, a bad system problem could make attempts to write to or open /dev/console fail or (worse) block. The equivalent "safe thing" is writing to the Mach "console" device directly.

Currently, the essential servers open the Mach "console" device directly and do their output to that (via a special stdio stream made with mach_open_devstream). The bootstrap filesystem (libdiskfs), init, and proc do this; auth doesn't, but in fact auth is so simple that it never has anything to print after initial startup. It is vital that these servers never risk blocking on any other server when writing their error messages. (They already depend on the kernel and the pagers backing their memory, i.e. the default pager and the bootstrap filesystem. Those are unavoidable.)

Probably the right thing to do is put a new Hurd-specific implementation of syslog in libc. This can use Mach IPC directly with low-level options to ensure that it doesn't block badly trying to talk to syslogd, and it can implement LOG_CONS using the Mach console device directly when possible. Such a new implementation is unlikely to go into libc 2.1, it will have to wait for 2.2.

An improved syslog would add robustness to every program using syslog and so is probably ultimately desireable regardless. But there is another notion that comes to mind for the essential servers. I am still ambivalent about this idea.

The idea is to use the "kmsg" kernel device for the essential servers' messages as well as the kernel's. We add support for opening the "kmsg" device for writing, to allow user messages to be appended to the internal buffer the same way as kernel messages are. The essential servers can then use this device to write their error messages; because it is a kernel device that cannot block, they can use it as freely as they would the Mach console device. When and if klogd and syslogd run, they will suck up the messages from the essential servers along with the kernel messages. Since the kmsg device is a nonblocking device with a fixed-size internal buffer used as a ring, this is most like what happens on Unix (and Linux). It also has the same properties that you could conceivably arrange to retrieve a kmsg buffer from memory on warm reboot after a crash, and see the dying messages from both servers and kernel.

I'm leaning away from this idea though. It just seems non-Hurdy.

4. Partitioning

20 Aug 1999 - 22 Aug 1999 (6 posts) Archive Link: "Hurd install: Can't open server boot script."

Topics: Bootloaders

People: Gordon MatzigkeitMike Hansen

Mike Hansen used the tarball method to install the Hurd, and got the error: "Can't open server boot script /dev/hd0s3/boot/servers.boot". Gordon Matzigkeit replied, "Are you *sure* it's hd0s3? GRUB's (hd0,3) is gnumach's hd0s4," and Mike replied, "Thanks. I am now the proud owner of a brand new Hurd system. :)"

5. The Future Of Mach

19 Aug 1999 - 25 Aug 1999 (6 posts) Archive Link: "The future of Mach"

People: Matthew Vernon

David Lazaro Saz had heard that gnumach might be on the way out, and asked if there was any truth to this. A number of people said that this would not happen in the near future, but Matthew Vernon added (the only dissenting reply), "The theory is that Hurd should be fairly readily portable to another microkernel. As a matter of fact, I'm looking into a possible replacement atm, so we may get the opportunity to try the theory out ;-)"

6. Disks Not Umounting Cleanly

23 Aug 1999 - 26 Aug 1999 (7 posts) Archive Link: "HURD not unmounting disks cleanly (not the old problem)"

People: Marcus BrinkmannPontus Lidman

Pontus Lidman found that his disks were not being cleanly umounted when rebooting with the 'reboot' command, and Marcus Brinkmann replied, "Fact is that nobody knows under which circumstances disks are not unmounted cleanly. I *know* that when you fsck under linux, you get a clean disk at next reboot, and if you don't screw up, it stays clean. But when you fsck under Hurd during boot time, it does not end up clean. I am not sure what happens if you e2fsck under Hurd manually (forcing)."

7. Proposal For Translator Management

23 Aug 1999 - 26 Aug 1999 (4 posts) Archive Link: "script for translator management"

People: Marcus BrinkmannKalle Olavi Niemitalo

Marcus Brinkmann made the following proposal:

I think we need a script for managing translators in /servers/ and a policy amandment to the Debian policy document, so all subsequent packages that provide translators for this directory have a consistent interface to the user.

As far as I can see, /servers/ is reserved for hooking in system translators, possibly in a subdirectory for grouping. Will it only be used by the Hurd itself, or is it true that additional translators (not in the main Hurd source) will hook in there? If the former is the case, a special script may be overkill.

The idea is that a package should honour configuration to the translators (like socket/2), but be able to update to new syntax et cetera if the user has not chnaged anything. This corresponds to Debian config file handling by dpkg.

A script would take a settrans argument line as argument, and optionally some more arguments which control how hard the script should try to get the translator in place (killing active translators etc). The script will check if the translatar has changed from the previous version provided by the package (if any), and see if the user has changed the translator (using showtrans).

Neither user nor package changed the translator:

If the package is installed, translator is set. If the package is updated, no action is taken.

Package changed translator, user not: New translator is installed.

Only user changed translator, package not: No action.

Both changed: Query user for action to take. Available will be several possibilities (installing new translator, no action, etc).

This only effects the passive translator. The active translator will left alone or killed or even forced to die, depending on additional options in the package script or on request of the user. The details have to be worked out (I have detailed information from Roland about how this works).

All translators below /servers/ should be managed by this script. A link like /servers/crash will be managed by update-alternatives.

Kalle Olavi Niemitalo replied, "Dpkg seems to leave *.dpkg-old or *.dpkg-dist files; would the script do something similar?"

Marcus replied:

This is indeed an interesting question.

This feature is definitely useful and wanted. However, I am not sure where to include this feature.

Note that the script must keep track of the translator in the package anyway, so it can find out if the transaltor was changed. It will keep a database somewhere. Suggestions about the exact location are welcome (somewhere under /var probably). This database will always contain the translators of the installed packages, and can be used to find out the ".dpkg-dist" information.

We have at least three options:

  1. Include the installed translator in the database, when a customised translator was changed to default (".dpkg-old").
  2. mv /translator /translator.dpkg-old resp. creating a /translator.dpkg-dist translator
  3. "showtrans /translator > /translator.dpkg-old" resp. "echo translator-information" > /translator.dpkg-dist.

Option 2 has the problem that we have passive translators that are not in use. Accessing them could have unwanted side effects (starting up a translator that should not be active). Therefore I am slightly in favour of 1 or 3. With 1, we could have a -query option for the user to find out which translator was originally there (or supposed to be there, resp). However, if it can be assured that the passive translators in 2. can not do any harm, this option is probably preferable.

8. Mounting CDs

25 Aug 1999 (2 posts) Archive Link: "Cds"

People: Mark KettenisMatthew Vernon

Matthew Vernon asked how to mount iso9660 CDs under the Hurd. Mark Kettenis replied:

That is indeed possible. The way to do it is very similar to the way you 'mount' an ordinary filesystem, except that CDs don't have partitions so you have to leave off the slice-part of the partition name. The translator to use is sofs'. Here's an example. Suppose you want to mount the CD that's in the CD-ROM player that's the master on the second IDE interface on the mount-point /cdrom. Then you would do:

# settrans /cdrom /hurd/isofs /dev/hd3

Note that this 'mount' will persist across reboots.

9. Many Machs

25 Aug 1999 (2 posts) Archive Link: "Which Mach is GNU Mach?"

People: Roland McGrathOKUJI YoshinoriPontus Lidman

Pontus Lidman gave a pointer to Mach4 UK22 Release Notes, and asked if the information there applied to GNU Mach. He also gave a link to Published And Unpublished Mach Papers, specifically the paper "An I/O System for Mach" by Alessandro Forin, David Golub and Brian Bershad; and asked if the I/O system described in the paper was present in gnumach.

To the first question, Roland McGrath replied, "Partially, but not completely. GNUmach was derived from that version and has the features it talks about, but other things have since changed, and the way you build GNUmach is different."

To the second, he replied, "Many research projects in the past were done based on Mach 3.0. There are many papers both describing the implementation techniques used in Mach at CMU and at Utah that are reflected in the GNUmach source base, and also many papers about projects that were not merged into the mainline CMU or Utah source base before it became GNUmach. That paper (from 1991) describes things done in the CMU implementation, and I think what it is describing is the state of earlier mainline CMU Mach 3.0 versions. But there has been much other work done since 1991, and specifically work using Linux device drivers at in Utah Mach4 (mostly by Shantanu Goel) and since in GNUmach (by OKUJI Yoshinori, who is on this list and actively hacks on GNUmach). If you want to understand things by reading old papers, then you should probably read all the related papers up to the most recent Mach papers (from Utah in 95 or 96 probably) to see the progression. And still, you need to just read the source to see what has been done in GNUmach since."







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.