These are things regarding which I would appreciate some input:

- The more I think about it, I think the way I hacked ext2 is the "right" way to transition to high UIDs.
A lot of people have been talking about a newer, better filesystem for Linux, but nothing has been done yet which is being tested on a large scale. My simple patch lets you easily move your ext2 filesystems into high UIDs, and lets you move them back without having to reformat or deal with a new filesystem.
More importantly, it's an extremely simple (stupid?) patch so there's very little that can go wrong. People who need high UIDs will probably need stability as well.
I know, I wrote into the "reserved" area of the inode--  but nobody else was using it :)
It seems to me that the next big new filesystem will be much changed anyway (i.e. 64-bit files on all machines) so in the long run people will end up chucking their existing ext2 filesystems and reformatting.

- Definitely, the next step is to modify glibc so that it automatically knows if it's on a high-UID kernel or a regular kernel, and act accordingly. Right now, if you install my patched glibc, it will die horribly on a regular kernel. Glibc should auto-detect this and act accordingly.
Something like this will also be necessary in order to enable full high-UID functionality with SysV IPC.

How does one go about doing this? There are much newer versions of glibc than the one I used. Should I be using them?

- What is the proper naming convention for RPMs? I just took the version number of the RPMs from Red Hat 5.1 (the most recent errata RPMs, that is) and incremented by 1. I would much rather have unique names, but I don't want RPM to freak out and think that "kernel-uid32" is something other than "kernel".
What's the proper way to name this package? kernel-2.0.xx-uid32-yy? kernel-2.0.xx-yy-uid32?

- I moved my 32-bit UID syscalls starting at #200, so that they wouldn't overlap with the new system calls in the 2.1 kernel. What does everybody think about this? Should I move them up even further? Right up to 254? (I realize they're not 'official' in any way)

- We'd like to see 32-bit UIDs get into Linux once the new development kernel is underway.
What do people think about backwards compatibility? Should the existing kernel syscall API be kept in place for 16-bit UIDs, and a new set of 32-bit UID syscalls be added like I've done with 2.0?
Or should all the old stuff get chucked (for size and speed), and leave it up to glibc for binary compatibility? (and just tell people to stuff their old libc5 and statically linked stuff)

- If you look at my patched kernel in include/linux/highuid.h, note that there are two defines, MAGIC_HIGHUID and DEF_HIGHUID. MAGIC_HIGHUID is used as a magic value to tell the filesystem driver that a high UID is lurking. DEF_HIGHUID is returned to user applications via 16-bit system calls when a UID would overflow.
I had these defined to different numbers, but then decided to change them both to 65534 (65535 is probably unlucky because it can mean -1 in 16 bits). Any reasons for/against having these two different numbers, or the same?

- System calls for 16-bit UID compatibility don't return an error if a UID overflow would occur. The rationale for this is that there are going to be a lot of libc5 or static programs out there yet, and returning an error is probably a good way to get core dump or total failure. In my opinion it was better to just return a fake value. Then you can put user "highuid" as 65534 in your /etc/passwd, and whenever it comes up you'll know you're dealing with an old program.
Of course, any programs run as root will hopefully be using glibc and thus be able to use high UIDs directly. Any libc5/static daemons will hopefully setuid() only to a low UID user...

- I probably didn't need to change ALL of the syscalls into 16/32 pairs that I did. Isn't it the case on Intel at least that registers are 32 bits anyway, so in many cases syscalls are being passed 32 bit variables even when they are prototyped to 16 bits?
Is there any reason to NOT make 16/32 pairs out of some of the syscalls that I did, and just keep one 32 bit version?
(Not all syscalls can get away without a 16 and 32 bit version-- for instance, setreuid() uses an argument of -1 to signify "don't change the UID", and -1 is a different thing in 16 bits and 32 bits)

- There are definitely going to be other broken things if anyone starts exploring with this patched kernel. Process accounting, for instance, seems to be hard-coded to 16-bit UIDs and so will break. Various utilities for managing the passwd file/ user list also seem to be be broken. (have I said this enough times already)

- 64 bit UIDs?

- Chris Wing - wingc@engin.umich.edu - 12/1/1998