[lkml]   [2000]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.240 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site