Subject: Re: dev_t changes & partitions
To: Bill Studenmund <firstname.lastname@example.org>
From: Todd Vierling <tv@NetBSD.ORG>
Date: 01/13/1998 19:00:58
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:
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
===== Todd Vierling (Personal email@example.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