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