> The work for enabling larger dev_t's has been done a long time
> ago (2.1 something, or even much earlier). AFAIU, glibc is also
> prepared for a larger dev_t. The big problem is doing it, as it
> will break _everything_.
Surely that depends how it's done.
I made a proposal relating to this some time ago, and the only
comments received back were to the effect that my proposal would
indeed mean that little if anything would be broken, but as far as I
can tell, it was otherwise ignored. Perhaps somebody can advise why?
For reference, I proposed that we move to at least 32 bit dev2_t (or
kdev_t or whatever one wishes to call them), split into three parts as
follows:
1. Bits 0 to 7 of the value comprise the MINOR number of the
node, identical to at the moment.
2. Bits 8 to 15 of the value comprise the MAJOR number of the
node, identical to at the moment.
3. Bits 16 up of the value comprise the FAMILY number of the
node, this being the new section.
Having split the value up like this, the results can be displayed as
triplets of the form (FAMILY,MAJOR,MINOR) to indicate what is what.
The field I have labelled FAMILY can then be defined along the lines
of the following for block devices:
* FAMILY = 0 is defined as "Compatibility Nodes". These are
handled by a special remapping module that takes the MAJOR
and MINOR of the value and remaps them to the equivalent
of whatever that maps to using the current (MAJOR,MINOR)
number scheme.
* FAMILY = 1 could be defined as "EIDE Devices", and would
be mapped such that MAJOR selected the relevant device, &
MINOR selected the partition thereon. This would allow up
to 256 drives with up to 256 partitions on each of them.
* FAMILY = 2 could be defined as "SCSI Devices", and would
be mapped such that MAJOR and MINOR had exactly the same
meaning as for "EIDE Devices" described above.
* FAMILY = 3 could be defined as "PCMCIA Block Devices",
and would be mapped similarly.
* FAMILY = 4 could be defined as "USB Block Devices", and
could be mapped such that MAJOR defined the relevant USB
bus and MINOR defined the particular device thereon.
A similar scheme could easily be defined for character devices, in
which the definition of "FAMILY = 0" would be identical to that above.
One possible definition would be:
* FAMILY = 0 is defined as "Compatibility Nodes". These are
handled by a special remapping module that takes the MAJOR
and MINOR of the value and remaps them to the equivalent
of whatever that maps to using the current (MAJOR,MINOR)
number scheme.
* FAMILY = 1 could be defined as "Miscellaneous Character
Devices", with MAJOR defining the category therein, and
MINOR the device within that category. Possibilities:
(1,0,*) Software devices /dev/null
(1,1,*) Virtual Terminals /dev/tty1
(1,2,*) Serial Interfaces /dev/ttyS0
* FAMILY = 2 could be defined as "PseudoTerminals" with
MAJOR and MINOR being treated as a single 16-bit number
that selected one of 65,536 available pseudoterminals.
This is the mapping that the current /dev/tty[a-z][a-z]
would be remapped to, although longer names would be
required.
* FAMILY = 3 could be defined as "PCMCIA Character Devices"
and would be mapped appropriately.
* FAMILY = 4 could be defined as "USB Character Devices",
and would be mapped appropriately.
Perhaps somebody can advise what is wrong with this idea? Nobody did
last time I proposed it, but it appears to have otherwise been
ignored.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/