[lkml]   [2000]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 2.3.39 has 32bit uid. What about 32bit pid?
    In <85t517$1o4$> Linus Torvalds ( wrote:
    > In article <>,
    > <> 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..

    Do this mean that ipc_pid_t will be extended ?

    > Linus

    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 13:55    [W:0.019 / U:7.488 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site