> > Note that you've found references to 'ipc_pid_t'. I've already included
> > support for 32-bit pid_t in my patches to the IPC code, needed to support
> > 32-bit UIDs there.
>
> Bonus.
The rest of the kernel already uses a 32-bit type for pid_t, but prevents
pids from exceeding 32767.
>
> > Now, actually supporting 32-bit (or 31-bit :) pids will require other
> > changes, and will possibly break many non-glibc programs...
>
> As long as the user code interace to the new glibc uses 32 bits for pids,
> I'm a happy camper. The kernel can catch up later.
>
> I wonder how many programs use -1 for uid 65535?
Only poorly written ones, I hope. Anyway, most of the programs that really
need to use UIDs/GIDs are run as root, and compiled from source, which
makes converting to 32-bit UIDs fairly painless.
The problem with a 32-bit pid_t is that an old libc5 program that fork()s
and has a child with pid >32767 is going to break when it tries to send a
signal to the child. There is no nice way to fix this; the only workaround
I can think of is hacking the old libc to remap pid numbers in user space.
Ick.
-Chris
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/