lkml.org 
[lkml]   [1999]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Migrating to larger numbers
    Guest section DW wrote:
    >
    > alan:
    >
    > > I'd give NFSv2 another 30 years. I believe NFSv4 draft is also 32bit
    >
    > NFSv2 has a 32-bit rdev field.
    > NFSv3 has a 64-bit rdev field, split 32+32.
    >
    > Andries
    >
    > [By the way, if I am not mistaken, this NFS point is really very minor.
    > I cannot see how it matters in the choice between 32 and 64.
    > In my representation (32+32 unless 16+16 unless 8+8) it would mean
    > that 32+32 device nodes can only be exported over NFSv3.
    > If we change to 64-bit immediately, but leave the high order half
    > zero at first then all is fine. When people need more than 32 bits
    > they'll also have to upgrade to NFSv3. Reasonable enough.]

    It doesn't even need to be the top 32 bits; we can export any 32 bits we
    want. This seems to me to be the right way to go, given that we're
    already carrying the overhead in glibc.

    --
    "The user's computer downloads the ActiveX code and simulates a 'Blue
    Screen' crash, a generally benign event most users are familiar with
    and that would not necessarily arouse suspicions."
    -- Security exploit description on http://www.zks.net/p3/how.asp

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:0.025 / U:60.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site