Messages in this thread | | | Date | Mon, 31 May 1999 12:18:22 +0300 | From | Matti Aarnio <> | Subject | Re: Migrating to larger numbers |
| |
On Sun, May 30, 1999 at 10:44:38AM -0700, Tim Smith wrote: ... > Uhm...32 bits will cover 4 billion users. Still, considering the trend > toward ISP mergers, and the trend toward everyone getting online, it might > be a good idea to allow everyone on the planet to have a unique uid, and > so going past 32 bits could be a good idea.
I *do* serve several 100k ISP customers per box with about 15 UIDs in the system. All those customers have *same* uid. So, I don't see that "uid equate to user" is necessary unless you really want to support NFS/CODA/AFS mounts to billions of people.
Of course, doing NFS support at campus-wide setup is an interesting thing all by itself, but that is *not* a thing that any sane ISP would do!
> How many problems would be introduced by making them both 128 bits and > using the UUID algorithm to generate uids and gids?
A lot! Going to 32-bits with current glibc-2.1 things is easy, because the userspace is already 32-bits and "all" you need are new syscalls with enlarged __kernel_uid_t and __kernel_gid_t, but going into larger ones will cause pain in form of requiring a set of new syscalls *AND* user-visible libc changes forcing to change also lots of programs now using uids and gids. Things might not be as simple as 'just recompile'...
Using 64-bits allows treating them as integers, but 128-bits are not usually supported as integers by gcc/egcs..
Also, unless you want to make things to perform poorly at all of these popular register-poor intel based systems (hopefully ia-64 is radically different!), then you should NOT use even 64-bit values more than absolutely necessary!
> --Tim Smith
/Matti Aarnio <matti.aarnio@sonera.fi>
- 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/
| |