"Chris G. Demetriou" <cgd@pa.dec.com> writes:

> 
> (1) what's the 'native' way of storing wedge information, if any?  You
> indicated that you'd want wedgeconfig to be able to understand all the
> partitioning types we currently support, but you don't provide a
> tool/format to store this information.  Some stable, per-disk storage
> mechanism is necessary.  That might be 'disklabel,' but that seems
> ... less than optimal for what you're proposing.

I'm not sure this question makes sense.  By default, the installation
tools should use whatever partitioning scheme is most appropriate for
that particular type of machine -- on PCs, the MBR; on Amigas, RDBs;
etc.  `Labels' should be valid on all systems if people want to use an
architecture-neutral format (but one which is incompatible with other
OSes).

People already have to deal with two types of partitioning on many
systems -- one for the boot ROM, and the other for NetBSD.  Currently,
some ports quite bogusly override what disklabel(8) does completely
and don't even support native `labels'.

I don't see this as being any more confusing; in fact, it would be far
more consistent across platforms.  Unlike the rather complex and
frustrating way things are done now, there would be no magic.

> (2) How do you mount root off of an alternate root device, e.g. when
> booting with 'askname' or if the kernel doesn't 'understand' the
> device you've booted from (e.g. can't get to it, because it's on a
> controller for which there is no driver; not as odd as you might
> think)?  "Please don't say you have to specify block offsets."
> This isn't really a 'legacy' need, so it's not clear to me that the
> pseudo-device you suggest would be particularly appropriate.

In a (user-space) devfs world, I envision the directory structure
looking something like:

/dev/sd0/raw
	 mbr/0/raw
	     1/raw
	     2/raw
	     3/raw
	 bsd/0/raw
...

We have to teach libsa how to find a random wedge anyway, so I suggest
that something like the above would be a reasonable thing to do.
(Presumably, mount(8) and disklabel(8)-equivalents would check whether
the target is a directory and add the `/raw', as a matter of
courtesy.)

There are at least two possible solutions to dealing with RB_ASKNAME:

1) Put all of the information on how to handle partitions into the
kernel, and just leave it there.  This is undesirable, in that it
bloats the kernel substantially just for the case of booting.
Especially if you (as I do) consider it a requirement that we deal
with all types of partitioning on all ports.

2) Since libsa already has to deal with this, modify the boot blocks
to allow specifying the root and dump partitions and pass in wedge
information for both of them, and *remove* RB_ASKNAME from the kernel
(except as part of the old boot block compatibility).  (While I'm sure
this will inspire lots of flames, I note that *no* non-BSD systems I'm
aware of have this functionality, and in practice I've never seen
anyone else use it.  It didn't even completely work in 4.4BSD, and
only gave you one shot as specifying the device names anyway.)

> (3) "When random potential users see this, what other thought are they
> going to have than that NetBSD developers engage in random drug
> testing?"  Partitions of various flavors have well-known and
> well-understood behaviours.  (Even Mac people understand partitions,
> though"Slices" are generally understood as well.

And the Mac people could continue using partitions just as they were
before (but with different device names).  `wedgeconfig -a' by default
will do exactly what people expect.

Slices, in fact, are extremely confusing.  They essentially require
the user to deal with 3 ways of doing partitioning *all the time*.  My
proposal allows the user, in a default installation, to use exactly
one partitioning scheme.  A PC user doesn't *need* to know how Mac or
Amiga or Sun or ... partitioning works, but it's always there if they
need to use it, and there's a consistent interface for it.  Slices
simply don't provide this functionality; they are a hack to deal with
a specific case, and are completely non-extensible.