Actually, I've long been of the opinion that we should use more major
numbers. It doesn't make much sense to use the same major number for
different controllers, and I think we could use dynamic mapping of _major_
numbers within controllers. Each controller (*) that is found gets a major
number of its own, with some very simple algorithm (reserve najor numbers
256-384 for SCSI devices, increment for each controller, something like
that).
(*) Some people start to worry about hot-swapping controllers, but that's a
red herring. You have to load the driver anyway some way, so it's ok to just
give a new controller a new major number at that time. That way all old
devices will have the same number within one Linux boot cycle, and if you
reboot after having added a new controller I don't really see the problem
with using some kernel command line options to tell the kernel that the root
device may have changed - we _cannot_ guarantee the same device number if you
add controllers anyway.
So use the major number as a controller index (that's really what the major
number is supposed to be, anyway), and the minor number as the disk index.
There must be some way to pack SCSI disk info into 20 bits (8+8+4?).
Note that this has one more added advantage: it's easy to keep the old SCSI
major number with the dynamic minors alive. The low-level controllers won't
need to know, because this translation could be transparently handled by some
higher-level translation code: the old major numbers get translated to the
32-bit device numbers and this can all be transparent to the user (so that
old setups continue to work despite the changes to disk numbering).
Note that having one major number per controller has lots of other
advantages: it means that controllers don't have to know about each other,
because they have complete control over their own major (unlike now, where
all controllers have the same major, and one of the things the SCSI layer has
to do is to separate out all the disk requests to different controllers and
drivers).
I don't see any problems with this approach, anybody else?
Linus