I don't think the kernel should address individual partitions.
On the PC alone there are many ways to partition a disk.
Such as: primary, extended, BSD, SCO, several disk managers,
Windows NT mirrored disks, and a variety of corrupted partition
tables left by fdisk for so many different types of OS.
Some tool can be used to give the kernel offset/size data.
> Also you are assuming that scsi is set in stone and isn't
> changing. We don't want to build in some 640Kb types of
> limitations just to solve this problem for some people.
>
> For some concrete examples, consider that scsi3 extends the lun
> to 5 bits. In SSA, the ID number is extended to 7 bits.
Ok, that is 12 bits.
> We also need to identify what type of controller we are talking to.
> Remember that we can have multiple controllers on the system, so we
> need a unique identifier. Consider that we have 20 some odd supported
> controllers now, so we want to at least allow for 64 or even 128.
> 7 bits here.
>
> Next, remember that we support more than one of any different type
> of controller. We need to do it in such a way that we can identify a given
> card even if others get added. We probably want full 16 bits here, since we
> might need to track things like I/O port address, PCI slot, etc, etc.
These two go together. At the extreme, 16 bits will do.
> Consider that some cards drive multiple channels. Currently some
> cards support 2, but I don't see any reason why more couldn't be
> added. We could say 4 bits here just to be safe.
OK.
> We still have 4 bits required for the partition ID for disk drives.
Maybe.
> Where do we stand? We have 5+7+7+16+4+4=43 bits. Even a symmetric
> 64 bit dev_t woudn't be able to express this.
I calculate 32 bits max. (with 4 bits for partitions)
There is no need for dev_t to be symmetric, and no need for the division
to be the same for block and character devices. You could just double
every estimate I gave to fill 64 bits, then put IDE and all the
proprietary CD-ROM controllers in with the SCSI devices. Forget about
the major/minor stuff.
If you really want to encode the partitions, that requires about
16 bits. primary:2 extended:4 slice:4
> It would be theoretically possible to give a seperate major number
> to each different type of scsi controller. This would shift some
> of the bits to the major number, and if this were done correctly we
> might be able to make things fit in a 64 bit symmetric dev_t.
Think of device numbers as being like IP numbers. You can then split
them in arbitrary ways using a bitmask.
> I have seen some people argue for solutions that work for the small
> systems, but exclude the large systems. I believe that this is
> fundamentally wrong, since the problems with dynamic address shifting
> grow as the number of devices on the sysetem grow. We should be
> looking for solutions that work in the case of large systems (with
> say 500 or more disk drives), and then make sure that this works
> well for the small systems.
People do this because:
Small systems outnumber huge systems in a big way,
perhaps 10000 to 1 depending on your definition of huge.
It is assumed that admins of large systems are really good at
dealing with problems.
On a big system, 500 disks appear as less than 20 because they
go into RAID boxes
A system with 500 disks does not use PCMCIA and/or docking station.
> Note that with the current system, there can be a maximum of 16 disk
> drives (since 16 * 16 partitions = 256 = max minor number). Clearly
> a larger dev_t is needed, no matter how we do it. We need to somehow
> agree on how large this needs to be, and *then* we need to fix the
> filesystems so that they store a dev_t that is this large.
For now, a quick hack would be very helpful. With a different
major number, controller:1 disk:3 partition:4 would work.
I have a concern about 64-bit dev_t. Would it be as fast?
I am most worried about the idea of sparse numbers.