Messages in this thread | | | Date | Mon, 07 Jun 1999 14:07:18 -0700 | From | "H. Peter Anvin" <> | Subject | Re: Migrating to larger numbers |
| |
Alan Cox wrote: > > > Guess what? We *ALREADY* depend on these -- dev_t in libc6 is a > > 64-bit number. > > And NFS is a 32bit dev_t encoding. so while we can go to 64bit, its > simply digging large holes and jumping down them. Nobody currently needs > more than a 32bit dev_t. 4096 different device types, some multiplexed > each with a million minors ? I think we can scale past the IBM mainframes > just fine in 32bits.
4096 is the part that worries me, it doesn't seem like an unreasonable number. Basically, I'm worried that with 32 bits we'll end up with a split that will be problematic on both ends for some device.
> 64bits means we have to screw up the NFS client, we won't be able to do > NFS root for all devices and worse.
The NFS argument is strong, although the counter-argument would be that we're localizing the damage. We can say: "fine, we use 12:20 for NFS; we expect that will be sufficient for the time being, but use 32:32 everywhere else -- that way if we run out, we'll only have to worry about NFS."
Then we can hope that NFS v2 (v3 as well?) are dead or dying when this becomes a problem.
-hpa
-- "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/
| |