Bigger process IDs and "dev_t"s (was: Re: RISC v. CISC...)

[Guy Harris]

>(Random thoughts...  People at Amdahl are starting to worry that
>the next generation of Amdahl mainframes might be able to support
>64K concurrent processes, or at least enough processes to make
>pid's wrap way to frequently.  Has MIPS started worrying about
>the problem of 16-bit pid's yet?  Seems like MIPS might run into
>trouble in 1990 or 1991...)  (16-bit major/minor device numbers
>are already too small for a 5890 [have you ever tried to configure
>3000 terminal devices in an 8-bit field?]  How much trouble is
>MIPS having with this 16-bit limit?)

Yes, both process IDs and "dev_t"s need to be bigger.  I think AT&T may
have discussed the notion of "expanded fundamental types" in the S5R4
developer's conferences.  At least on some architectures, you may want
to increase the size of both process IDs and "dev_t"s; you will probably
have to change the system call numbers for at least some system calls
that use those types (probably just the calls that deal in structures
containing those types; other calls can probably stay the same -
"getpid" returns an "int", which is 32 bits on 32-bit machines, and
"kill" takes an "int" as an argument) and introduce new versions with
new system call numbers.

Another problem with short "dev_t"s is that transport protocols will
probably be implemented under streams (or STREAMS, what the hell) as
multiplexing drivers supporting cloning, so that the moral equivalent of
"socket()" would be an "open()" of "/dev/<protocol>", which would clone
a new minor device, giving you a fresh line into the protocol in
question; on a big machine, I could easily see >256 TELNET or "rlogin"
connections alone, so you'd run out of clones fairly quickly....