Subject: Re: partition bookkeeping
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 09/22/1999 18:39:04
> Right now we have 20 bits for the minor number.  We're talking about
> new disklabels/wedges, and everyone seems to be happy with 64
> partitions per disk.

...for now. :-)

> That's 6 bits, which leaves us 12 bits to specify the disk.

This assumes you use a scheme for mapping between minors and wedge
partitions similar to what disks currently use.

Since wedgeconfig probably has to frob stuff in /dev anyway, there's no
need for this.  There's no reason that a disk with four partitions
can't use only four minors while one with 9 partitions gets 9 minors,
etc.  They don't even have to be contiguous, which is semi-necessary if
you expect to be able to re-label so as to add partitions at runtime.

> [...stuff about c0t0s0 style naming and why we can't do it, basically
> not enough bits in the device minor...]

> That's why we wont' hard-code things.  It'd waste too much space,
> because you have to code for the max value when doing so, and all the
> cases which don't use anything near the max (like how most SCSI
> devices only use LUN 0) will just waste resources.

This is one of the arguments in favor of devfs (at least, those who
like c0t0s0 names might think so): it makes this possible.  There's no
reason you couldn't have minors allocated only for those devices that
actually exist; as long as /dev/dsk/dks0d2s5 gets partition 5 on device
2 on controller 0, nobody cares whether its minor number is anything in
particular.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B