> 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/