Won't work. First of all, for disks we need to be able to address
individual partitions. Right now we allow for 0-15, so you lose 4 bits
here. Thus we have only 4 bits left in which to encode scsi ID/lun, etc.
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.
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.
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.
We still have 4 bits required for the partition ID for disk drives.
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.
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.
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.
The scsidev program is basically sort of a band-aid until a better
solution arrives. I do believe that it should alleviate most of the
problems
that people are having until that time comes.
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.
-Eric
-- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep."