Re: Migrating to larger numbers

Matti Aarnio (matti.aarnio@sonera.fi)
Mon, 31 May 1999 12:18:22 +0300


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/