Messages in this thread | | | Date | Mon, 31 May 1999 03:50:46 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: Migrating to larger numbers |
| |
H. Peter Anvin writes:
> 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.
I can see a couple good arguments for going to 64 bits.
First there is the argument given by the Samba developer. This is just obvious: no more need to map UID values.
Second is the same argument for a 128-bit IPv6 address. Sparse allocation lets a large organization with a unified UID space divide up UID granting by location.
> dev_t: 32 bits minimum, suggest 64 bits (split 16:48, 24:40 > or 32:32).
Oddly, Compaq's "Tru64" has a 32-bit dev_t with a 12:20 split. I don't think Linux should haul around twice as much data unless there is a really good reason for it, and I don't see such a reason.
> SOME PEOPLE HAVE SUGGESTED: > > off_t, time_t, ino_t.
ino_t is important for dealing with some large foreign filesystems. (NTFS, UDF and XFS at least, sometimes even over NFS)
I'd still love to see time_t out of the kernel. POSIX says absolutely nothing about what raw system calls return, and 64-bit nanoseconds would be better. Userspace may want 64-bit seconds, a struct with two values, or anything else you might imagine. Userspace may be Wine or a JVM. BTW, 64-bit nanoseconds solves the year 2038 problem _and_ provides high resolution in a mathematically usable manner.
- 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/
| |