I don't actually think we should do this the way Jes implies.
I _do_ think that we should have an added level of indirection between the
devices and the device numbers, though. Every time larger device numbers
come up, the added indirection also tends to come up.
In short, I think it makes sense to have a better mapping from device
numbers to actual devices, and I _don't_ think that this mapping should be
done by the device layer, it should be done at a higher level. A better
mapping gives us:
- binary compatibility. Imagine a platform where you want to support
different device numbering schemes by different systems. You may want
to make the device numbers more "virtual", in that they might depend on
the type of process you're running.
- sharing majors between devices. Right now this is rather painful, and
we have this "misc" device for a specific subset of this (mice and
other random devices that tend to need only one minor number). But if
we again had this mapping done in a more generic way, we could for
example have two different SCSI device drivers that wouldn't have any
common ground, and instead of having the SCSI driver figure out what
the major means, we'd have the device mapper just do it at a higher
level so that the devices really could be totally independent.
- IO request queues. Right now the IO requests are done according to
major number, but if we had a better internal representation we could
make the IO request queues be per-device (or per-driver, depending on
how the driver wants them). Again, the reason why we queue them per
major is not because we want to, but because we want to do the queuing
at a higher level that doesn't know about driver internals. If we had a
"mapper" level for device numbers, we could do much better queueing.
- performance. 16-bit device numbers are actually _bad_ for performance,
because on many architectures (including intel, although less so than
with some others), accessing and comparing 16-bit entities is slower
than using pointers or other more "native" data structures. Using
another format internally may be advantageous.
- backwards compatibility - when device numbers change, the drivers
themselves wouldn't need to worry, only the mapper would be implicated
(this is kind of the same issue as binary compatibility).
and
- the above case: we could much more easily pack different drivers to use
the same "major" because the drivers themselves wouldn't even know.
In short, I'd actually like an approach where kernel internals use a
opaque "device ID" - that doesn't have a minor or a major associated with
it at all.
As mentioned, this has been talked about before, and I think Andries
Brouwer actually had patches to do some of it (the "device ID" being a
pointer to a device block).
Linus