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

[Guy Harris]

>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.

Yes; when the topic of stretching "dev_t" came up in discussions between
Sun and AT&T, this was noted (although somewhat in the context of a
32-bit "dev_t", with perhaps 8 bits of major and 24 bits of minor).

>Ignoring network filesystems for the moment, it's clear that we are
>undersupplied with minor numbers and oversupplied with major numbers.

Actually, network file systems require chunks to be taken from block
device space, where there tend to be relatively few different device
types.  Furthermore, if you formalize the current informal hack ("block
device" major/minor pairs with the 8th bit of the major device number
actually refer to remote file systems), and limit block device majors to
at most 127, you only steal at most half the space of major devices.

>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.

You may end up having to Huffman-code them on some systems; SunOS 4.0
currently has about 56 major devices in use (don't try to assert that this
is just Sun being wasteful unless you have hard evidence, please), of
which I suspect at most 10 could be nuked if you e.g. nuke the Sun-2
line.  That leaves 2 bits to hand to the minor device field; I suspect
1024 TCP connections would be sufficient for now, or 1024 tty ports, or
1024 pseudo-ttys, but I could see that limit being exceeded one day.
 
(Fortunately, Sun RPC doesn't require individual connections per client,
at least when connectionless protocols are used; I don't know whether
RFS would, for example, require one connection per client, but if it did
I could see some popular server requiring > 1024 connections.)

I don't know how many major devices a mainframe would typically need,
but it may be fewer, so you could give more bits to the minor device.

Then again, you can "repartition" those bits, with a variable-length
encoding scheme, trivially, as long as you un-do the PWB-vintage hack
(which persists in S5, although it's not in V7 nor in BSD) of having the
kernel strip the major device number from the "dev_t" before passing it
to the driver - just assign more than one major device number to a
driver.  Not optimal, but that's life....