On Mon, 5 Oct 1998, Greg A. Woods wrote:

> [ On Mon, October 5, 1998 at 11:04:00 (-0700), Bill Studenmund wrote: ]
> > Subject: Re: Another changer, another changer problem
> >
> > Why are we transitioning to 22-partition diskabels? That limit only
> > applies to the *BSD label. MacOS-based labels can have any number of
> > drives. In fact, we could have the pathelogical case of someone having 64
> > partitions! Also, w/ MBR disklabels, we could get more than 22 partitions
> > on a drive (if you have multiple OS's and each one has support for lots of
> > partitions).
> > 
> > :-)
> 
> I'm sure glad that smiley is there Bill, but not so glad as I suspect
> some other folks are!  ;-)
> 
> Sure, it would be cool to have an operating system that you could plug
> any old disk into and be able to read the data from it.  That's sort of
> where you could go if you added native fdisk support not only to the
> i386 kernel, but to all of them.  I could then take a Linux/OS2/NT disk
> and mount all the partitions from it on my sparcstation.

To be blunt, given how multi-platform NetBSD is, I think we SHOULD be able
to take any disk from any machine we support and stick it in any other. As
you mention below, we don't need to support everything in every kernel.
But we need the support.

> I agree though that all that bloat shouldn't be in every kernel.  I just
> think it would be nice if you could get that code in there when you want
> it.  Yes, one can use user-land tools that access the raw disk, and in
> theory one could even convert something like mtools into a user-land
> loopback filesystem.....  That might be better, actually, *except* on
> the native platform (eg. FDISK labels should be in i386, and maybe MacOS
                           MRB labels?
> labels should be in mac68k, etc. -- even NetBSD/sparc *could* require
> layering with native Sun labels and put the NetBSD label inside a
> V_UNASSIGNED partition ;-).

Other than that I'd stick MacOS, ISO9660, and MBR support in all of my
kernels, I agree.

The place things will get harry (and which is another thread) is when we
support MBR's in MBR's or any other layering where the partition layout is
generated from multiple (recursed>) disklabels.

Take care,

Bill