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

Henry Spencer henry at utzoo.uucp
Tue Nov 8 05:03:35 AEST 1988


In article <385 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:
>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...

I'm afraid that I do assert that this is just Sun being wasteful, for
the sake of its own convenience.  How many machines do you know that
actually have all 56 types of devices on them?  None, I bet.  Using
the same major number for device XYZ across all machines is basically
an administrative convenience, not a logical necessity.  The number
of major numbers *needed* on a given machine is the number of devices
actually attached, plus a few for things like /dev/mem, minus a few
for devices that always go together (e.g. most of the stuff on a Sun
CPU board) and hence could share a common major number (as /dev/null
and /dev/mem do).  Abandoning the standard devicetype->number mapping
would obviously make system setup harder, but Sun really needs to get
some competent people to put in some effort in that area anyway...

Note, I'm not saying that there has been anything *wrong* with wasteful
assignment of major numbers in the past; the costs have been small and
the convenience significant.  But if we're looking at trickier encoding
of dev_t, that changes the tradeoffs, and rethinking is in order.
-- 
The Earth is our mother.        |    Henry Spencer at U of Toronto Zoology
Our nine months are up.         |uunet!attcan!utzoo!henry henry at zoo.toronto.edu



More information about the Comp.unix.wizards mailing list