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.060 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site