One thing I think we should do with the 32-bit dev_t conversion is
change the number of partitions per disk. Not only are more partitions
one specified reason for 32-bit dev_t's, but messing with the partition
number will precipitate a device node mess.

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.

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).

Take care,

Bill