Subject: Re: why is partition c always the full disk?
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <email@example.com>
Date: 07/15/1998 14:30:08
On Wed, 15 Jul 1998, der Mouse wrote:
> >> [...], because someone (mycroft, I think it was) already committed
> >> the following [major/minor/makedev macros]
> >> In short, we *already* have 32-bit dev_ts, with 20 bits of minor
> >> number, and all existing device nodes continue to work Just Fine.
> > Yes, but other than the dial-in/out flag for tty's, we don't use more
> > than the first 8 bits or so.
> That was meant as a reply to the person who (correctly) pointed out
't'was me. :-)
> that 16 partitions means one more bit for the partition number and
> hence one fewer bit for the drive number - the point being that a
> system with 8 bits of minor number and 8 partitions can have up to 32
> devices per driver, but with 16 partitions, on 16 devices. Apparently
> this is a real limitation for a few of the biggest NetBSD systems out
> there. My point was just that that is currently a non-problem.
> > The idea is to tie the switch to using a new major number for a block
> > device. A device node with the old major number has 8 partitions,
> > and a device node with the new major number has 32 partitions.
> No reason it couldn't be done...though it would be a little ugly,
> because it would mean that not every driver could use the DISKUNIT and
> DISKPART macros.
[*] more below
> I've been trying to come up with a way of handling this automatically
> at boot time: have userland look at /dev and tell the driver how many
> partitions per drive /dev appears to be expecting. (For people who
> have unusual ways of doing /dev for some reason, the userland program
> could also take an overriding value on its command line instead of
> always looking at /dev.) The biggest problems arise when your boot
> device isn't drive zero of its driver - there's no *conceptual*
> problem, because disk minors are conceptually <drive,partition> pairs.
> But that's not how the existing internal interfaces work.
This was exactly what I was championing at one point.
[*] Actually we can still use the DISKPART/DISKUNIT macros. They get
passed the DEVICE node! So we could conditionalize the output on the
device number. Major numbers in one range of values take MAXPARTITIONS ==
8, and major numbers in other ranges can take other values. So there'd be
one sd (wd, cd, ...) major number which has 8 partitions per unit, and
antoher which has, say, 32. You could mix and match them in one /dev and
all would be well. Obviously a node trying to use a partition over 8 would
have to use the new major number.