Re: Migrating to larger numbers

H. Peter Anvin (hpa@transmeta.com)
Mon, 07 Jun 1999 14:07:18 -0700


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/