> Well, I got the Hurd installed (using the GHHK), built a cross-compiler, > rolled my own GNUMach and Hurd kernels, and compiled a few packages.
That's great! You are not so naive if you've gotten this far by yourself. > 1) At startup, GNUMach tries to run an irq probe on all my drives (and > fails). Is this to be expected? It doesn't seem to cause any problems, > but it is a bit disturbing. I don't really know. It is certainly the case that by default you will get a kernel with every device driver available turned on to autoprobe. You can use the --enable-* and --disable-* options defines in i386/Drivers.in to select a subset of drivers to include. The support for setting detailed parameters for specific drivers is pretty lacking right now. If you have an issue with the device drivers, you might try the patches in ftp://alpha.gnu.org/gnu/hurd/contrib/gnumach-1.1.3-linux-2.0.34-drivers-beta1.patch.gz; these are from a Japanese contributor whose name slips my mind at the moment. I expect we will fold these changes into gnumach; we just haven't had time to look at them yet. But since many of the gnumach drivers are glued-in linux drivers, these updates may affect you. > Also related to startup: what switch can I use with gnumach on the GRUB > command line? You can give various flags with normal -x syntax, that are collected into a single string of -xyz and passed to serverboot, and you can give root=DEVICE with a device name that will be the last arg to serverboot. serverboot groks -a to prompt for root device and -q to prompt for boot script (normally /boot/servers.boot) and then runs those. The -xyz string is then available as ${boot-args} in the boot script, and normally this is passed to the Hurd boot filesystem (ufs.static or ext2fs.static) as --bootflags=${boot-args}. The filesystem (this code is in the Hurd diskfs library) groks -q to prompt for the Mach device for the root filesystem, -i to prompt for the name of init (normally /hurd/init), and passes the flags through to init. init groks -q to prompt for the names of the servers (/hurd/foobar) and -s for single-user. Oh yeah, I think several spots along the way support -d to do various frobs to let you attach the debugger. I hope somebody puts all this in some FAQ if it's not already there. > 2) Is it worthwhile to try and build a native compiler, or is the > cross-compiler adequate in most cases? The cross-compiler itself should certainly be just fine (i.e. produce all the same code for all the same things), and running big builds on a stable system like Linux is certainly going to be a lot faster than the Hurd is in its current state of development. There are two reasons to favor doing native compilation. Firstly, the real problem with cross-compilation is packages that are not well set up to be cross compiled; many more packages can be cross-compiled with little or no hassle than used to be, but I'm sure you will still run across many assumptions that break when cross-compiling. The second reason is that doing big builds on the Hurd is a good way to hammer on the system and find bugs. But since there are definitely bugs, you may not want to deal with the hassle of being bitten by them yet, while we're still working on putting together a sanely organized whole system. (Right now, it's probably more helpful to get more packages built so more people can bang on them in a straightforward way.) > 3) I'm not planning on installing X anytime soon, but I am curious: > given that I have a Linux partition on the same machine that is visible > to the Hurd (or should be, once I figure out translators), can I share > much of my existing X installation? And given that most people > installing the Hurd at this time probably also have a Linux partition on > the same machine, would it make sense to put together minimal versions > of some of the bigger packages (e.g., X or Emacs) for people who can > share the non-OS-specific parts from their Linux partitions? Yes, you can share some data just as you can between multiple machine architectures or OS's served by a common NFS server or whatever. The Hurd is not binary compatible with Linux, so you cannot share the program and library binaries; but all the miscellaneous data, site config files, fonts, elisp code, etc, you should be able to share just fine. Everything in /usr/X11R6/{doc,include,man,share} and in /usr/X11R6/lib/X11 should be shareable; for emacs and other packages, probably everything installed in /usr/share or /usr/local/share (that's why it's called that). There might be some site- or host-specific configuration files sprinkled in there that you don't really want to share, but the issues are not new or different with the Hurd than with other OS or machine combinations where sharing works.
