Re: size of pid_t (was: Re: NR_TASKS as config option)

[Ralf Baechle <ralf@uni-koblenz.de>]

On Sun, Jun 13, 1999 at 08:47:08PM +0200, Andries.Brouwer@cwi.nl wrote:

> Changing the size of pid_t to 64-bit is a major operation.
> Lots of system calls have pid_t arguments or return pid_t
> results. And pid_t occurs many other places. For example,
> a struct flock has a pid_t field.
> Moreover, glibc doesnt have machinery in place to change
> the size of a pid_t. So, if I am not mistaken, this would
> require a new major number for the library.
> 
> But if pid_t is 32-bit, then why does the kernel only use 15 bits?
> We have
>         #define PID_MAX 0x8000
> in <linux/tasks.h>, and at first sight not much goes wrong
> if we pick some larger number for PID_MAX, like 0x7fffffff.
> (There are some comparisons around, so for simplicity we should
> keep PID_MAX positive.)
> 
> 
> Hmm - but then what is it that goes wrong?
> In include/asm-i386/posix_types.h we have
>         typedef unsigned short __kernel_ipc_pid_t;
> (and the same for m68k, ppc, sparc, arm).

Alpha, MIPS and Sparc64 on the other side do use a 32-bit *pid_t and
are limited by the current implementation to effectivly 15 bit.

> This is the type of the fields msg_lspid, msg_lrpid, shm_cpid, shm_lpid
> of struct msqid_ds and shmid_ds. Such structures are returned by
> the system calls msgctl() and shmctl().
> So, using larger pid's gives some trouble with SYSV IPC.
> (And again glibc is unable to cope with changes, although
> the trouble is minor in this case.)
> 
> 
> Conclusion:
> - a 64-bit pid_t is most convenient for the kernel, but
>   gives trouble with libc.

Note that I have a chance for a fresh start for MIPS64.  Binary
compatibility is therefore not an issue.  Furthermore it's a 64-bit
architecture, so the code size itself will not increase.

The biggest problem will probably be code which does things like

  int pid;

  pid = fork();

Finding them all is going to be quite a nasty problem.  Making the kernel
/ libc reject pids that are signed / unsigned expanded 32-bit numbers
except init's pid will support that, hopefully.

> - a 32-bit pid_t is what we have today, but we use only
>   15 bits because of SYSV IPC (or perhaps other reasons
>   I am unaware of).

Pids in the range of [0 ... 32000[ are pretty much tradition among
unices since about the time UNIX was born.  Linux does things slightly
more efficient by using the entire range of [0 ... 32768].

  Ralf

-
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/