Subject: Re: Thoughts about wedges
To: Charles M. Hannum <>
From: Chris G. Demetriou <>
List: tech-kern
Date: 09/26/1999 08:10:58
"Charles M. Hannum" <> writes:
> Uh, I feel I have to comment here...
> I *NEVER* proposed `[losing] the RB_ASKNAME functionality'.  If you
> read my original message on this subject, the following was fairly
> clear:
> Boot blocks already have to know about partitions, in order to find
> kernels.  The proposal was to move `the RB_ASKNAME functionality' from
> the kernel to the boot block.  Given this and wedges, the kernel would
> not need to know about partitions at all, thus completely eliminating
> a large pile of divergent code.
> The ability to specify a different root partition would still be
> present; it would just be in a different place.

and in a place that won't work for all ports.

Some ports' boot blocks (e.g. alpha's) cannot easily access disks
other than that being booted.  that would mean a very significant
reduction in RB_ASKNAME's functionality, if this need were pushed into
the boot blocks.

Other ports' boot blocks (e.g. i386's) don't necessarily display an
obvious correspondence between the device names/numbers used in the
boot blocks and kernel device names/numbers.  This makes RB_ASKNAME
harder to use successfully, and may actually put you back into the
position where the boot blocks can't access everything the kernel can.

Some ports (e.g. NetBSD/arm32 on shark) don't _have_ boot blocks at
all because the firmware directly loads and runs their kernels.  While
it'd be nice to write boot blocks for them, it's a non-trivial

I would suspect there are also issues around what you could do with
x86 network boot ROMs, too.

I think if you want to avoid a large pile of divergent code, it's
_much_ easier to do that in the kernel than in the boot blocks.

The boot blocks, if any, for a given platform _must_ diverge from
other ports boot blocks by necessity, at least to some degree, and
further must operate under significantly different sets of constraints
(e.g. which devices they can easily access).

It just doesn't make sense to push complexity down there, when what's
desired is uniform code and interfaces to be presented to the user.

Chris Demetriou - -
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.