Linux-kernel mailing list archive 1999-23,: Re: Migrating to larger numbers

# Re: Migrating to larger numbers

H. Peter Anvin (hpa@transmeta.com)
Tue, 08 Jun 1999 16:47:14 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alan Cox: "Re: Devfs, was Re: Migrating to larger numbers"
- Previous message: Nathan Hand: "Re: 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/

- Next message: Alan Cox: "Re: Devfs, was Re: Migrating to larger numbers"
- Previous message: Nathan Hand: "Re: Migrating to larger numbers"