Subject: Re: dev_t changes & partitions
To: Todd Vierling <tv@NetBSD.ORG>
From: Bill Studenmund <email@example.com>
Date: 01/13/1998 15:58:22
> 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:
> 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.