lkml.org 
[lkml]   [1999]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Migrating to larger numbers
Sure, and who would have expected 4.2 billion IP addresses to be allocated
(note: allocated, not used). There are other advantages to having a large
uid/gid (IP, memory, etc, etc) space, many of which haven't even been
thought up yet.

The real question is whether or not it's worth it to slow down the 32-bit
processors with a 64-bit datatype. Are uid/gid used often enough that this
would cause a significant slowdown in the operation of the kernel? Are
64-bit processors so close on the horizon that they will be common enough
when 2.4 (3.0?) is finally released?

But there might be a way to compromise: Would it be possible to make
uid_t/gid_t implementation specific? As I read it, __kernel_time_t is an
unsigned long. If my memory serves (which is growing less and less likely
these days), this means that it is a 64-bit value on 64-bit architectures
and a 32-bit value on 32-bit architectures. This is the route that Sun
took with their 64-bit architectures with time_t, based on the (IMO
perfectly valid) assumption that in 38 years 32-bit binaries will be done
with.

So on 32-bit platforms you'd have:
32-bit uid_t
32-bit gid_t
32-bit time_t
etc, etc

and on 64-bit platforms you'd have:
64-bit uid_t
64-bit gid_t
64-bit time_t
etc, etc

If you want more than 4.2 billion users or you want to use your machine in
2039, get an alpha, ultra sparc, 64-bit PowerPC, or ia64. :-)
-Rob

On Mon, 31 May 1999, Augusto Cesar wrote:

> Date: Mon, 31 May 1999 13:51:57 -0300 (EST)
> From: Augusto Cesar <bishop@sekure.org>
> To: James McCollough <jamesm@gtwn.net>
> Cc: Nicholas Tufar <nt@yargitay.gov.tr>, H. Peter Anvin <hpa@transmeta.com>,
linux-kernel@vger.rutgers.edu
> Subject: Re: Migrating to larger numbers
>
> On Mon, 31 May 1999, James McCollough wrote:
>
> > > > > Okay, 2.3 is out; it's time to get some fundamental data types
> > > > > expanded:
> > > > >
> > > > > REQUIRED:
> > > > >
> > > > > uid_t, gid_t: 32 bits minimum, 32 bits probably OK.
> > > >
> > > > Some ISPs and mail servers may have more than 65536 users on one system.
> > > > I would propose to make uid_t and gid_t 64 bits.
> > > >
> > >
> > > I vote for 32 bits, *some* ISPs have more than 65536 users, but they can
> > > find others solutions, like using SQL databases for users accounts, if we
> > > use a gid_t of 64 bits its more 32 bits for every gid_t variable, this
> > > will increase up the size of kernel and decresing the speed with a feature
> > > for only a couple of ISPs. IMHO.
> > >
> > 16-bit range = 0 to 2^16 = 0 to 65,535
> > 32-bit range = 0 to 2^32 = 0 to 4,294,967,296
> >
> > unless you have more than 4.2 billion users, 32-bit uid_t and gid_t types
> > should be adequate.
> >
>
> sorry, I confused with 16-bit, so reinforcing my opinion, 32 bits its the
> best option, 64 bits never, will much increase the size of kernel.
>
> 16bit = 0 to 2^32 = 0 to 65,535
> 32bit = 0 to 2^32 = 0 to 4,294,967,296
> 64bit = 0 to 2^64 = 0 to 18,446,744,073,709,551,616
>
> so what machine will have 18,446,744,073,709,551,616 of users? :-)
>
> --
> Augusto Cesar
> Sekure SDI
> http://www.sekure.org
>
>
>
> -
> 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/
>


-
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.068 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site