Messages in this thread | | | Date | Thu, 13 Jan 2000 21:26:50 +0100 (MET) | From | Andries.Brouwer@cwi ... | Subject | Re: Linux 2.3.39 has 32bit uid. What about 32bit pid? |
| |
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/
| |