> The advantage, as I see it, is that it lets you deal with multiple OS's on
> an MBR disk. Right now, we look through the MBR for a NetBSD partition,
> and then look in there for the disklabel for the whole disk disklabel.
> FreeBSD looks for a FreeBSD partition, and looks in there for a FreeBSD
> disklabel. Same with OpenBSD and Linux. One problem is that each OS will
> then basically ignore the other OS's partitions, a bad thing if you want
> to inter-operate between OS's.

It will ignore the MBR partitions of the other OSs.  Do you really suggest
that we implement the disklabel scheme of every other OS in the world?
_In the kernel_?

IMHO our disklabel should allow for a large enough number of partitions, and
the user should enter any partition he wants to access into our disklabel
(as is already current practice).  Probably there should be some utility
per foreign disklabel that assists him in the process.  It probably would
also be a good idea if the kernel would allow for the user to only set the
incore disklabel.  Combined with the previous conversion utility this should
do everything that one would want, doesn't it?

> I liked the idea of making slices vnodes on the fly. My idea is, for each

_If_ by this you are talking about the generation of a fake disklabel
from the MBR records (including MBR records in extended partitions) as is
done in the powerpc port, this code is by yours truely.  And this is kludgy
enough to not make me want to add support for yet more random disklabel stuff.

> disk drive which will support slices (wd and sd), there is a companion,
> sliced major device. The sliced device would support 4 sub-units of the
> un-sliced device.
> 
> The only real difference between this idea and automatically sticking a
> vnode on each MBR partition is that the unit number of the "sliced" device
> and the "unsliced" device would match, and that the slice is selected from
> upper bits in the sub_unit field. As I understand vnd's, each vnd would
> get its own "unit" number. 
> 
> When the disklabel for the real ("unsliced") device is read, it would
> configure the sliced device appropriatly. Appropriately means setting up
> slices on an MBR drive or setting up a pass-through layer for a non-MBR
> drive (so wd0a could always point to the "sliced" layer and things would
> work irregardles of the disklabel type).
> 
> I really don't like stuffing slices in the same device as the "real" disk.
> When you have slicing happening, you're talking about having multiple
> layers of disklabels. Without some sort of two-layer scheme, we have to
> tuck two or more disklabels into one unit. That strikes me as kludgy,
> messy, and bound to be a pain. Also, I agree that we really want to leave
> ourselves as many units as we can (think running NetBSD on a multi-headed
> husge server. It's a cool thought! :-)
> 
> So if the disk has an MBR disklabel, the sliced drive would be broken into
> 4 chunks (one per possable MBR partition), each subsection's disklabel is
> read if we understand it. Then each chunk gets set up by the relevant
> disklabel. If the disk has another type of label, we just set up a 1-to-1
> correspondance between "sliced" and "unsliced" partitions.

What about extended partitions?  If you don't know, this is a MBR partition
that itself has an MBR and further partitions.  I'm not sure with how this
works in x86 machines, but with powerpcs you can have these arbitrarily
stacked.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800