But part of the advantage with having larger majors would be that they
could be sparsely allocated. For example, Foobar Associates is making
a line of telepathic communicator cards. I would like to, as Device
Registrar, to allocate a range of majors in advance to Foobar
Associates. This results in poorer utilization. A rule of thumb is
that the density of a numbering space is inversely proportional to the
logarithm of the size. So N bits can, in reality, hold 2^N/N numbered
gizmos.
That being said, I think 16 bits will be enough for a long time as far
as majors is concerned. Minors, on the other hand, can always use the
space. POSIX.1 does require that dev_t is an arithmetric type, which
means that a 64-bit dev_t would require that Linux permits "long long"
in the offical Linux APIs for 32-bit machines. Since "long long" is a
GCC-ism, it seems to me Linus has been avoiding making it mandatory in
user space. There are a few more issues; a 32-bit dev_t would
maintain the alignment of struct stat, which would make backward
compatibility easier to implement.
-hpa
--=20
PGP public key available - finger hpa@zytor.com
I don't work for Yggdrasil, but they sponsor the linux.* hierarchy.
"The earth is but one country, and mankind its citizens." -- Bah=E1'u=
'll=E1h
Just Say No to Morden * Save Babylon 5: http://www.babylon5.com/cmp/sup=
port/