lkml.org 
[lkml]   [1999]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.081 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site