> 
> On Tue, 13 Jan 1998, Bill Studenmund wrote:
> 
> : If we change partitions at the same time as dev_t's, we can reduce the
> : mess. If we get a 16-bit dev_t for a disk device, then in the process
> : of making it a 32-bit dev_t, the compatability code would move the
> : minor # around for the new setup. This way, a kernel can boot with old
> : device nodes and still work right. If we did it any other way, we can
> : get a MESSY upgrade problem.
> 
> Well, I've already determined (at least for me) that it's so hairy to allow
> a system to boot on old /dev nodes.  I'd love to be proven wrong, but after
> two days of looking at the screen and oodles of printed kernel source, I
> have decided that it is much easier for kernel hackers and end users to
> upgrade /dev just before rebooting into a new kernel.

Hmm. Well, I'd still vote we change the minor split when we change
dev_t's. That way we rebuild devices only once. :-)

> This partition nuberr change can just be done right now by changing
> DISKUNIT()/DISKPART() (and the MAKEDEV scripts). 
> 
> : How many partitions do we want? I'd vote for 32. (a) that covers
> : how many can fit in one disklabel block (22 I think). (b) that provides
> : room for 4 slices of 8 each (if MBR disks go for the slice system).
> 
> hm, that sounds good... but this arrangement was mentioned earlier and I
> found it intriguing:
> 
> xxxxxxxxxxxx  xxxx xxxx
>      12        4    4
>     unit     slice part
> 
> This would, incidentally, be very readable in hexadecimal format:
>   0x01C0061B
> is device 0x1C (28), unit 6, slice 1, partition 11.
> 
> This format provides for 4096 units per device.  (Sound decent enough...?) 
> As long as we stick with the sequential-numbering device format, it is a
> good match. 

Hmmm. I guess 8 bits would be fine per drive.

Though who, other than MBR drives, will use slices? I thought other
disklabels will just have oodles of partitions.

Take care,

Bill