To: linux-kernel@vger.rutgers.edu From: torvalds@transmeta.com (Linus Torvalds) Subject: Re: Linux 2.3.39 has 32bit uid. What about 32bit pid? Date: 16 Jan 2000 11:09:27 -0800 In article <UTC200001152131.WAA07579.aeb@arend.cwi.nl>, <Andries.Brouwer@cwi.nl> wrote: > > No, its worse sadly -- think fcntl(fd,F_SETOWN,&pid) sort of thing. > We will need a new F_SETOWN or esle the SIGIO stuff will break. > >But where is the problem? >Let me repeat: pid_t has *always* been 32-bit. >In libc5. In libc4. In Linux 0.01. Indeed. In fact, I think that in Linux 0.01 it actually _used_ all bits. I remember how I was chasing a strange bug in bash, which turned out to be because _bash_ used "short" somewhere to store a pid. And this was long long before Linux development and me became arrogant enough to say "oh, bash is broken, tell Chet to fix it", so what I ended up doing was to just make sure that yes, "pid_t" was still 32-bit, but we only ever selected pids in the 15-bit range. We could start using 32-bit pid's any day, but for (a) /proc and (b) I'm not sure what makes sense in a cluster. Do we want to have the high bits be just high bits, or do we want them to be cluster machine ID, or do we want them to be thread-ID related? So the dynamic range of pids stays at 15 bits until it's clear what the right thing is. The type stays at 32 bits.. Linus - 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/