Re: Migrating to larger numbers

Michael Meissner (meissner@cygnus.com)
Mon, 7 Jun 1999 17:48:28 -0400

On Mon, Jun 07, 1999 at 02:07:18PM -0700, H. Peter Anvin wrote:
> 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.

Well you could always use an internet IP style addressing format (ie, if the
first byte is < 128, you get 24 bits for the minor number, otherwise you get 16
bits for the minor number).

I recall that when I worked for the Open Software Foundation, their solution
was a system call that gave you the shift/mask amount to separate the major and
minor numbers (ie, if you needed more minor numbers, you configured the kernel
to use maybe 12 bits for the major number, and 20 bits for the minor number).
We modified the library and include files to use this system call.

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482


-
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/