Messages in this thread | | | Date | Mon, 31 May 1999 14:09:31 -0400 (EDT) | From | <> | Subject | Re: 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/
| |