Hurd Traffic #43 For 12 Apr 2000

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

Mailing List Stats For This Week

We looked at 33 posts in 111K.

There were 19 different contributors. 7 posted more than once. 4 posted last week too.

The top posters of the week were:

 

1. Hurd Success; Accessing FAT Filesystems; Listing Active Translators
2 Apr 2000 - 3 Apr 2000 (3 posts) Archive Link: "Some simple questions."
Topics: FS: FAT, FS: ext2
People: Neal H WalfieldMarcus Brinkmann

Mike Burns successfully installed the Hurd from the tarball, and compiled Gnumach by hand with no problems at all. He had a few questions though. First of all, he wanted to mount a Zip disk containing a FAT16 partition. He'd checked out the translators in '/hurd', but none of them seemed to work. Neal H Walfield replied, "Currently, the hurd can only read ext2fs and vintage ufs partitions. A fat translator has yet to be written." And Marcus Brinkmann added that 'mtools' might be a suitable workaround.

Mike also asked for documentation on 'settrans', and asked how to get a list of all the active translators. For docs, Neal replied that '--help' would work on any GNU tool, including translators. He added that 'settrans' had an info page as well. As far as listing active translators, he admitted there was "no good way. This has to do with the message passing properties of hurd/mach. Try showtrans on a node to see how it is setup. However, since you are only looking for active translators (ie those running, correct?) you could to ps -A and figure it our yourself."

Mike also asked how to set up swap, and Marcus told him to check out '/etc/fstab/index.html' or '/boot/servers.boot'.

 

2. Porting libgcj
3 Apr 2000 - 4 Apr 2000 (5 posts) Archive Link: "libgcj note"
People: Tom TromeyChris Lingard

This was covered in Issue #41, Section #6  (25 Mar 2000: 'libgcj' Ported To The Hurd) . This time, Tom Tromey from Cygnus reported that Joerg Brunsmann had pointed him to that discussion in the archives (http://www.debian.org/Lists-Archives/debian-hurd-0003/msg00297.html) ; Tom added, "We're interested in porting libgcj as widely as possible. If you're interested in getting Hurd patches into the libgcj distribution, contact me and I'll provide information on what you have to do. It isn't hard (the hard part is filing FSF paperwork)."

Chris Lingard replied that he'd been the one who'd posted the patches, but that he wasn't happy with them. They were not properly tested, and were also very hackish and not clean. Tom replied:

I didn't read the patch, so I don't know how hackish it might be.

As for testing, if dejagnu works on Hurd then you can just use "make check". You need a special version of dejagnu :-(. But I can point you to that if you want.

Send libgcj patches to java-patches@sourceware.cygnus.com. If they are nontrivial (> 10 lines) you'll need FSF paperwork in place before we can check them in. If you plan to do the port I recommend starting on the paperwork now. I can give you pointers for this.

Chris replied, "Send me the paper work. The patch (hack) is 223 lines; 119 lines being in boehm-gc. When it tests successfully, and I have improved the patch I will send it in." Tom replied:

For boehm-gc you can send the patches directly to Hans Boehm "hans_boehm@acm.org".

For libgcj you can find the paperwork here:

http://gcc.gnu.org/contribute.html

I recommend filling out paperwork for "libgcj", "gcc", and "classpath" -- that will be sure to cover you regardless of what you patch. I believe you can do this with one set of paperwork by filling in the blanks in the appropriate way.

 

3. Installation Report
4 Apr 2000 (8 posts) Archive Link: "Another installation report (quite long)"
Topics: Emulators: VMWare, FS: ext2
People: Colin WatsonMarcus BrinkmannMatthew Vernon

Colin Watson installed Debian Hurd under VMWare. He described his hardware, "I'm working on a P3-450 with 160Mb of RAM, 48Mb of which is currently allocated to the Hurd, and (luckily) IDE disks." He reported:

the installation sequence I used (after several abortive tries) was as follows:

Download and edit the tools, inc. cross-install;

(By the way, there's a bug in cross-install with respect to the current woody archive, as libreadlineg2 is now in oldlibs.)

mke2fs -o hurd -L debian-hurd /dev/hda5

(I initially tried to use a VMware "virtual disk", effectively a filesystem mounted loopback from a file, but I found it to be more trouble than it was worth as in order to access it in Linux I had to use the provided vmware-mount.pl which uses the network block device, and I seemed to be tickling bugs in this which meant that I had to reboot rather more often than I wanted to.)

mkdir /gnu
mount -t ext2 /dev/hda5 /gnu
./cross-install /gnu
mount -o remount,ro /gnu
(amusing effects without this ...)
vmware
...
./native-install

I also used grub-boot-0.5.93.1.image from the GNU FTP site. (At least one of the links I found to this was out of date and wouldn't boot for me; I believe it was the one from the GNU mirror of Matthew Vernon's guide, which I was following.)

The first thing I noticed was that, when I use Ctrl-Alt-Esc to get VMware to relinquish keyboard focus, or when I hit various other modifier-key combinations, I get one of the following errors on my Hurd console:

kd_setleds1: unexpected state (1)
kd_setleds1: unexpected state (2)

Oh, and during the boot process I get the following disk read error, which I don't see when booting Linux:

Partition check (DOS partitions):
hd0: hd0s1 hd0s2 < hd0s5 hd0s6 >
hd1: hd1s1 < hd1s5 hd1s6 hd1s7 hd1s8 hd1s9 hd1s10 hd1s11 >
com0: at atbus0, port = 3f8, spl = 6, pic = 4. (DOS COM1)
com1: at atbus1, port = 2f8, spl = 6, pic = 3. (DOS COM2)
com2: at atbus2, port = 3e8, spl = 6, pic = 5. (DOS COM3)
hd02: bad access: block=28, count=2, blockend=30, nr_sects
end_request: I/O error, dev 03:02, sector 28

I *think* the extended partition on hd0 is fine. (Shouldn't the "bad access" message talk about hd0s2, by the way?)

I tried to run native-install, anyway, and found that it invariably hung partway through for no well-determined reason. The fallback console doesn't seem to know about Ctrl-C (can this be fixed?), so I'd no way of aborting and had to hard-reset the VMware box (which of course left my filesystem slightly corrupted, but I don't think it did any harm). The second time through it made it to the end, but I still have a sense of flakiness about the system - it's hung similarly once or twice apart from during the initial installation process, I had a "Computer bought the farm" during native-install once, and I'm getting the "default pager" errors which I've heard are a known problem.

I had problems with ae, too; when I tried to edit /etc/hostname with it it refused to write it out with a trailing newline, which led to my login banner and my prompt being corrupted with odd control characters. This could be a bug in ae rather than the Hurd, though, or even a bug in me as I don't normally use ae. :)

Marcus Brinkmann replied with some comments. Regarding Colin's 48M of RAM, Marcus said:

48 MB is enough, however, you must add a swap space, or the Hurd will be less reliable (don't ask...).If you don't have a partition to spare (it can be a linux swap, but obviously not the one you already use for the underlying running linux), you can use a file on disk.

dd if=/dev/zero of=/gnu/swap bs=1024k count=64

And then, in /gnu/boot/servers.boot:

/dev/hd0s2/swap $(add-raw-paging-file)

Regarding 'libreadlineg2' being in oldlibs in Debian Woody, Marcus replied that this had been reported earlier as well, and was being fixed. The 'hd02: bad access' error, Marcus said was harmless, though it would be nice to fix it.

 

4. Debugging The Mach Microkernel
5 Apr 2000 (2 posts) Archive Link: "debuging mach"
People: Roland McGrathDaniel Wagner

Daniel Wagner wanted to start debugging the Mach kernel. He'd been reading the sources, but this had not managed to answer all his questions, and he was curious about other ways of debugging. Roland McGrath explained:

If you want to use gnumach's built-in debugger (aka ddb and sometimes called kdb), then the thing to do is start the kernel with the -d switch (in a kernel compiled with --enable-kdb). Then you should get the debugger prompt immediately on boot. You can then set breakpoints whereever you like to stop and examine the kernel. Note that this is a primitive debugger, not a source-level debugger, and in fact we don't even support getting an ELF symbol table into the kernel debugger so you don't get any symbols at all.

If you use oskit-mach, it supports (that is, the oskit supports) using gdb over a serial line from another machine. That is by far the best way to debug the kernel. You use gdb and have nice source-level debugging and most everything you are used to from using gdb on user programs. If you can do this (i.e. have two machines and a serial cable) and want to, then you should get started first by debugging some oskit example kernels using gdb over your serial line. There is a debian package of oskit that you can easily install to build your kernels, though I would recommend compiling it yourself from source with -g. You should refer to http://www.cs.utah.edu/flux/oskit/ for information about the oskit and how to set things up to use gdb over a serial line (or at least where to ask for advice, which is not here). Once that is all working for you and you have gotten a feel for using gdb with an oskit kernel, just build oskit-mach with -g and you can debug it like other oskit kernels.

 

5. Getting Started Writing Translators
6 Apr 2000 - 7 Apr 2000 (5 posts) Archive Link: "Server programming"
Topics: FS: FTPFS
People: Marcus BrinkmannNeal H WalfieldMoshe Zadka

Daniel de Kok was very excited to start writing Hurd translators, and wanted to start by writing an HTTP server. Marcus Brinkmann was a bit skeptical about how useful a Hurd-specific HTTP server would be in general, and added,
It's probably more useful and not so difficult to write a httpfs, a filesystem server that "mounts" a http tree to some inode, just as ftpfs does with ftp directories. Take a look at the ftpfs server in the Hurd source.
But he also encouraged,
Apart from that, writing translators (Mach servers) using the Hurd libraries is certainly the central point of the Hurd, and I hope you will have fun writing dozen of servers :)
Daniel replied that an HTTP server would just be a relatively easy way to get into the swing of writing Hurd servers, and said he might be interested in writing an httpfs translator. Neal H Walfield put in:

If you want to learn how to write translators, there a a bunch to get you started in the /src/hurd/trans.

From there, you can fix ftpfs (which is _very_ buggy) or write that httpfs translator or any number of others that need work.

If you are interested in progamming Mach only, there seems to plenty that needs hacking in both GNU/Mach and glibc.

Moshe Zadka added that, "httpfs sounds a bit bogus to me: URLs have no hierarchical structure whatsoever, and there is no concept of directory." End of thread.

 

6. System Clock Falling Behind
6 Apr 2000 - 8 Apr 2000 (5 posts) Archive Link: "Time."
People: Jim FranklinNeal H Walfield

Mike Burns noticed that his system time was being set back every time he used the hurd. Jim Franklin gave a link into the debian-hurd archives (http://www.debian.org/Lists-Archives/debian-hurd-9911/msg00145.html) , and also confirmed,
My internal clock is off as well. I use ntpdate on my Debian GNU/linux OS to keep the clock reset to the proper time. Every time I boot into Debian GNU/linux the clock is reset to the proper time. You might want to try porting it to the hurd if you don't have Debian GNU/linux installed as one of the OSes on your machine.
And Neal H Walfield said he didn't have any problems with the clock on his system; he suggested Mike's hardware might be suspect.

 

 

 

 

 

 

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.