From alan@lxorguk.ukuu.org.uk Thu Jan 13 16:45:46 2000
> I think we should change __kernel_pid_t now that we are changing __kernel_uid_t.
>
> a) It is easy - easier than the change to larger uid.
> Roughly speaking the only change is in the ipc structs.
> (The other part of the change is in /proc.)
Do libc5 and glibc give the illusion of a 32bit pid - I thought they didnt
Yes, they do.
Already Linux-0.01 uses
typedef int pid_t;
(and so does libc-4.4.1), so nobody has ever used a 16-bit pid_t
with Linux.
There are precisely two obstacles, and both are minor.
The first is SYSV IPC. It was introduced in 0.99.10,
and has always used an unsigned short (perhaps for binary compatibility?).
Thus, the pid information passed between kernel and user space using
shmctl() and msgctl() may be truncated.
However, 2.3.39 already uses structures that use pid_t instead of ipc_pid_t
so nothing needs to change in the kernel anymore, and any ipc-using application
that is recompiled today with the appropriate headers (using IPC_64) will
have 32-bit pid information.
Thus, if we change get_pid() so as to use pids larger than 32000
we need CONFIG_15BIT_PID (default=n) so that people who cannot or
do not want to recompile their ipc using stuff can use a new kernel.
(Only very few programs are affected. Making new rpms available
for people upgrading to 2.4 would suffice.)
Aha, so that was obstacle 1. Obstacle 2 is the inode numbering the kernel
uses internally for /proc. That would have to change.
Andries
-
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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:23 EST