lkml.org 
[lkml]   [1996]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: possible SCSI device numbering solution
    Date
    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/


    \
     
     \ /
      Last update: 2005-03-22 13:37    [W:4.107 / U:0.348 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site