The big change: all of the namespace problems should (hopefully) be fixed
now. This means that if you install these modified kernel headers, you
will still be able to compile programs under libc5, and you will be able
to recompile your C library (libc or glibc) without any unexpected
behavior.
It is tested and working on the i386 architecture.
The patches are available at:
http://www.engin.umich.edu/caen/systems/Linux/code/misc/2.3/19991204/
Changes in this version:
- care has been taken to not change names where it would break
libc5 compiles, or rebuilds of the C library.
The following names are now UNCHANGED:
__kernel_uid_t, __kernel_gid_t
ipc_perm, msqid_ds, semid_ds, shmid_ds
IPC_SET, IPC_STAT, MSG_STAT, SEM_STAT, SHM_STAT
__NR_chown, __NR_getuid, __NR_setresuid, etc. in unistd.h
fields uid, gid in struct stat
fields uid, gid in siginfo structure
The following names have been redefined or are new:
uid_t, gid_t
ipc64_perm, msqid64_ds semid64_ds, shmid64_ds
kern_ipc_perm, msg_queue, sem_array, shmid_kernel
IPC_SET64, IPC_STAT64, MSG_STAT64, SEM_STAT64, SHM_STAT64
__NR_chown32, __NR_getuid32, etc. in unistd.h
fields uid32, gid32 in struct stat
fields uid32, gid32 in siginfo structure
- It looks like my previous patches broke the core dump format on
arm, i386, m68k, sh, and sparc32. (oops) The ELF core format
should now be unchanged. (although it only supports 16-bit UIDs
on these architectures)
- the ncpfs and smbfs filesystems support ioctls which pass UID
information. These have been fixed up to avoid possible
problems.
- ntfs changed to use uid_t instead of __kernel_uid_t, therefore
allowing it to support 32-bit UIDs
- some updates made to the sparc64 code, completely untested...
If anyone is interested in reviewing the changes, the most important new
stuff is in the IPC patch:
http://www.engin.umich.edu/caen/systems/Linux/code/misc/2.3/19991204/linux-ipc.patch
***IMPORTANT NOTE***
This version of the patch fixes problems with compiling the C library.
Previously, I took advantage of these "problems" to generate a 32-bit UID
capable C library. Now, if you try to use the glibc patch I've posted
before, you will generate a normal C library that does not take advantage
of 32-bit UIDs. THIS IS A GOOD THING! Changes to the kernel headers should
not cause unexpected behavior when compiling old versions of the C
library.
I hope to have a new glibc patch available soon (next week maybe), which
will compile with 32-bit UID support against these latest kernel patches,
AND will provide complete backwards compatibility for old non-32-bit UID
kernels.
In the mean time, if you use a 32-bit UID glibc generated against previous
versions of this patch, it will work perfectly with this version of the
kernel patch to give 32-bit UID support for your glibc programs. There
have been no binary compatibility changes made in the patch.
Still known to be broken with these patches:
- sparc64 architecture.
Still untested:
- all non-i386 architectures
- all filesystems other than ext2 and nfs
Thanks,
Chris Wing
wingc@engin.umich.edu
-
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/