[lkml]   [1999]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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