Messages in this thread |  | | Date | Sat, 30 Sep 2000 01:51:36 +0200 | From | Andries Brouwer <> | Subject | Re: PIDs limited to 15 significant bits |
| |
On Fri, Sep 29, 2000 at 06:51:22PM -0400, Chris Wing wrote:
> > (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t > > is used for the fields msg_lspid and msg_lrpid of the (obsolete) > > struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete) > > struct shmid_ds. Nothing compiled today uses this, and almost nothing > > uses it at all, but this nevertheless means that one needs an option > > CONFIG_15BIT_PID (default=N) for backward binary compatibility.
> Just to clarify, the old struct msqid_ds et. al are still used by all > Linux software before glibc 2.2. As of glibc 2.2, there is a new > user-level ABI for the SysV IPC functions {msg,sem,shm}*(), which provides > 32-bit pids and 32-bit uids. All software using SysV IPC will need to be > recompiled under glibc 2.2 to take advantage of the new structures. > > I don't think that returning incorrect pids to older programs here is > going to be any worse than returning incorrect uids or gids. But, we > should fix the kernel to return (-1) in 16 bits, or something like that, > in case of a pid overflow, to programs using the older structures.
Perhaps. That doesnt help since old programs do not know that they have to test for some special value.
I think the appropriate thing is to return EOVERFLOW. That is defined by:
EOVERFLOW Value too large to be stored in data type.
precisely what we want here.
Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |