Re: Some naive questions
> 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.
Reply to: