Messages in this thread | | | From | (H. Peter Anvin) | Subject | Re: possible SCSI device numbering solution | Date | 26 Jun 1996 08:18:58 GMT |
| |
Followup to: <Pine.LNX.3.91.960625111607.815B-100000@gytha.demon.co.uk> By author: Bryn Paul Arnold Jones <bpaj@gytha.demon.co.uk> In newsgroup: linux.dev.kernel > > True, wasting 48bits of minors could be done, but I think that it will be > a very long time before we have 16bit's of majors (the way we're using > them now, it will be a very, very long time). >
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
-- 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á'u'lláh Just Say No to Morden * Save Babylon 5: http://www.babylon5.com/cmp/support/
| |