On Sat, 3 Oct 1998, Todd Whitesel wrote:

> > That's always seemed either like "magic" numbers, or inappripriate
> > overloading to me.  It's one thing to have a "convention" where a
> > certain slice represents the entire physical device, but yet another
> > thing entirely to encode that convention into the driver.  I'd much
> > rather see another minor number used to represent the raw disk,
> > especially since there's no big shortage of them any more.
> 
> Ooh, I would love to see this. I've always hated the "in-band" characteristic
> of the 'c' and 'd' conventions. It would provide an MI-acceptable way of
> getting these things out of the partition table, so that we could use the
> same device names on all ports without worrying.

The problem is that to put the "raw" partition out of band, we need
another major number dedicated to the drive type. So sd's would have two
devices, and wd's would have two...

As it is, we'll have multiple major numbers for disks soon anyway. Why
double that?

One of the big concerns with moving to 32-bit devices is that major
numbers made on a 32-bit aware system should work on a 32-bit unaware
system. The easiest solution was to make the unit/partition split vary w/
major number. Then you'd have 8-partition wd's, a dn 32- or 64-partition
wd's. That way, on an i386, major 0 would always be a wd w/ 8 partitions.
Out of band raw partitions double even that. 

> In the future I would really like to see compat code that lets us mount disks
> across all ports, and that means grokking i386 "doslabels" and Apple's own
> partition format (another c/d situation?) in an MI manner.

Apple's partition table problems are not with a c/d split. macXXX uses
partition c as the raw disk, like everything else. The Apple partitioning
problem is that: 1)  it's not position sensitive, so it's not obvious
what's a and what's b. Different formatters arrange things differently,
and they might sort the list so there's little corrilation between what a
user would see and what's on disk. Also, the Apple partitions deal w/ info
which the NetBSD disklabel format doesn't grok (partition type is encoded
in 16 or 32 char names). It's not the same as w/ MBR partitions in that we
don't have to layer a partition table inside another, but it is similar in
that disklabel isn't necessarily the right tool to use to edit the table.

> Anything that moves us away from implicitly used letters and toward
> documented partition types makes sense to me too.

?? diskabel's output always indicates partition type.

Take care,

Bill