On 26 Jan 1998, Charles M. Hannum wrote:

> 
> "Chris G. Demetriou" <cgd@pa.dec.com> writes:
[snip]
> 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.

I think the thing which is confusing is that we don't yet have a clear
picture of what the proposal will do. I think everyone's concerned about
details which probably won't be clear until we sit down with live kernels
and play. :-)

> > (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
> ...

Ok. So then on mac68k I would most likely make /dev/sd0e a symlink to 
/dev/sd0/hfs/0/raw ? I know this is what wedgeconfig would take care of.
I'd just like us to not have to run wedgeconfig to get the system up
(symlinks into a devfs would "just work").

I really like the idea of being able to handle multiple disklabel formats.
I'm glad someone who has a chance of getting it done is working on it!

Can we make it so that we can access multiple non-conflicting disk
partition layouts at once? The Zip Tools disks have both MBR and MacOS
(hfs) partitions on them. I think it'd be WAY COOL (tm) to be able to
access them both.

> 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.

How about we put a small (well, kernel-configurable) wedge configurer in
the kernel. GENERIC would probably only have the NetBSD and "native" 
formats. That way, when you boot single user, the typical disk labels get
read and set up for you. If not, one of the first things you'd need to do
(at least as I understand things, please correct me where I'm wrong) when
booting single user is run wedgeconfig -a. That seems prone to loose. 

We then have a more-featured wedgeconfig in user-space. It knows about ALL
the partition formats we choose to understand. That could be much more
than just the ones used by NetBSD. When it runs, it configures any
partitions/etc missed by the in-kernel configurer.

Take care,

Bill