Messages in this thread | | | Date | Mon, 14 Jun 1999 11:22:32 +0200 | From | Ralf Baechle <> | Subject | Re: 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/
| |