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

[Henry Spencer]

In article <314 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:
>>... (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?] ...
>
>...on a big machine, I could easily see >256 TELNET or "rlogin"
>connections alone, so you'd run out of clones fairly quickly.... 

I think I observed this on the net a while ago:  there is no inherent
reason why device numbers have to be split half-and-half between major
and minor numbers.  Ignoring network filesystems for the moment, it's
clear that we are undersupplied with minor numbers and oversupplied
with major numbers.  Furthermore, outside the kernel, very few things
know the split -- most things that look at device numbers do so to
compare the whole number to another, and don't care about the internal
structure.  It's quite conceivable to re-partition those 16 bits, or
even use a Huffmanish encoding that gives a few major devices lots and
lots of minor devices while still providing for a number of less
prolific major devices.

Clearly making dev_t 32 bits would make life easier, and it's probably
worth doing, but if the price in compatibility seems too high, there
are ways to at least partially solve the problems without breaking
compatibility.  Too many people are willing to charge in and break
things unnecessarily, when a bit more thought and a bit more effort
might yield a compatible solution.

Pids, now...  I don't think we're going to be able to avoid using 32
bits for them, but I don't think it will break anything much, since
most everybody uses ints for them already, and the 16-bit machines
aren't the ones with the problem.
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry at zoo.toronto.edu