There are two issues:
- the way how KERNEL represents the values (e.g. 16-bit uids)
- the way how LIBRARY represents the values (e.g. 32-bit uids)
The glibc-2.0.7-19 at i386 has 32-bit unsigned integers as uids.
It hides the __kernel_uid_t from the user.
This means:
We can *any day* change kernel to support 32-bit uids
at i386 (with new kernel syscalls) as long as we do
remember to write matching interface routines for the
glibc so that it can take full advantage of the result.
Dynamically linked software will be able to use the *new*
glibc to continue running, and also get the advantages of
the new kernel facilities, while *static* binaries may
have problems...
If you have written a code that does direct syscalls, you are
already in deep trouble with non-portable code, but you propably
were doing something low-level anyway.
I don't remember what libc4, and/or libc5 used for uid_t, was
it the direct kernel type ?
I feel quite confident about glibc that we don't have those problems
pestering the user-space, and thus code compiled for glibc-2.0
should be runnable for quite a while into the future. (Unless we
decide to do something radically different, and non-UNIX, e.g.
128-bit UIDs..)
As a test about that, I am running RH binaries compiled for glibc 2.0,
but I do have glibc 2.1. I broke only one set of binaries, but it
was doing unsupported library internal calls, anyway.
There are many issues where current library saves us, but there are
also issues, which are troublesome. One of those is support for files
of over 2 GB in size in i386 platform. Likely the LFS standard gets
us past the problem with its new syscalls, and new datatypes.
(Also somebody asked for solutions for the Epoch-Event at 2038 when
currently common 32-bit signed time_t wraps around... Alpha has it
as 64-bit signed value, so there the problem is already solved,
but others may experience some discomfort at running a bit oldish
binaries in systems then.. I might bet that by then every *running*
system has 64-bit time_t, and that their binaries are a bit newer,
than 40 years old...)
/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/