lkml.org 
[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: size of pid_t (was: Re: NR_TASKS as config option)
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/

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