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.

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. 

=====
===== Todd Vierling (Personal tv@pobox.com) =====
== "There's a myth that there is a scarcity of justice to go around, so
== that if we extend justice to 'those people,' it will somehow erode the
== quality of justice everyone else receives."  -- Maria Price