Newsgroups: comp.unix.wizards Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: Bigger process IDs and "dev_t"s (was: Re: RISC v. CISC...) Message-ID: <1988Nov7.190335.17023@utzoo.uucp> Organization: U of Toronto Zoology References: <156@gloom.UUCP> <6865@winchester.mips.COM> <468@oracle.UUCP> <314@auspex.UUCP> <1988Oct31.183021.13880@utzoo.uucp> <385@auspex.UUCP> Date: Mon, 7 Nov 88 19:03:35 GMT In article <385@auspex.UUCP> guy@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@zoo.toronto.edu