Messages in this thread | | | Date | Tue, 08 Jun 1999 16:47:14 -0700 | From | "H. Peter Anvin" <> | Subject | 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/
| |