>> sd0 at scsibus0 ....
>> -> sd0 raw partition at sd major, minor 0
>> -> label shows three partitions, #0, #1, #5
>> wedge covering sd0:
>> partition 0 ("sd0a") at sd major, minor 2
>> partition 1 ("sd0b") at sd major, minor 3
>> partition 5 ("sd0f") at sd major, minor 4

> That's a MUCH bigger change than what I thought wedges were supposed
> to be.  To really do this, we need a MUCH more sophisticated sytem.

I'm not convinced of the MUCH part of it.  (Obviously. :-)

It does have many of the same problems as the wedge-major scheme,
notably that preserving chown/chmod bits across reboots works only when
partitions, instead of just drives, remain constant.

> First off, we have to keep state (what minor's what).

You're keeping state in the disklabel (or wedge data structure, or
whatever you call the thing) anyway.  It's just distributing the state
a little differently.

> It would be really hard to do alternate-root boots.  /dev becomes
> history dependent...

wedgeconfig would more or less have to update /dev when it loads the
info into the kernel.

Yes, this means this scheme is difficult to make work in conjunction
with a wedge scheme that has any in-kernel partitioning.

>> Only if you insist on sharing major numbers.  I still don't see what
>> that buys you, aside from complicating every disk driver with wedges
>> instead of isolating the wedge layer cleanly off in its own driver.

(Since I wrote that, /dev state preservation was pointed out to me.)

> How is it complicating every driver?  They currently [...]

Complicating as compared to what they would be with a
single-wedge-major scheme, wherein the disk-specific drivers (sd.c,
wd.c, ra.c, etc) don't know *anything* about partitioning.

I think the biggest lose with device majors and unit/partition minors
(ie, the current major/minor scheme, more or less) is that I can't see
how to do recursive partitioning, except with something like ccds.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B