guy@auspex.UUCP (Guy Harris) (10/27/88)
>(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....
henry@utzoo.uucp (Henry Spencer) (11/01/88)
In article <314@auspex.UUCP> guy@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@zoo.toronto.edu
roy@phri.UUCP (Roy Smith) (11/02/88)
henry@utzoo.uucp (Henry Spencer) writes: > It's quite conceivable to re-partition those 16 bits Sounds like a job for devmask (analagous to netmask for IP subnets). -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
guy@auspex.UUCP (Guy Harris) (11/02/88)
>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....
kre@cs.mu.oz.au (Robert Elz) (11/02/88)
In article <1988Oct31.183021.13880@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > it's clear that we are undersupplied with minor numbers and oversupplied > with major numbers. Certainly true. > Clearly making dev_t 32 bits would make life easier, yes, what's more maybe we could do away with major *numbers* completely and use major *names* instead. 16 bits would be enough space for a 2 character name (which the whole universe, almost, could just treat as a number). Given this, all the absurd renumbering of all the entries in /dev every time someone rearranges [cb]devsw could be done away with once and for all. (Yes, I know that 2 chars isn't great, but it does fit). Imagine ... brw------- 1 root sd, 0 Oct 18 12:34 /dev/sd0a kre
jim@cs.strath.ac.uk (Jim Reid) (11/03/88)
In article <1988Oct31.183021.13880@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > ... on the merits/demerits of bigger dev_t's ...... >Clearly making dev_t 32 bits would make life easier......... This has already happened on some machines. Sequent have done this on Release 3 of their UNIX and I think Encore have done so too. They've had to do this because it's not unknown for their boxes to be configured for over 256 tty and/or ptys. Jim -- ARPA: jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
friedl@vsi.COM (Stephen J. Friedl) (11/05/88)
In article <1988Oct31.183021.13880@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > Clearly making dev_t 32 bits would make life easier, In article <1023@murtoa.cs.mu.oz.au>, kre@cs.mu.oz.au (Robert Elz) writes: > yes, what's more maybe we could do away with major *numbers* completely > and use major *names* instead. 16 bits would be enough space for a > 2 character name (which the whole universe, almost, could just treat > as a number). (Yes, I know that 2 chars isn't great, but it does fit). > > Imagine ... > > brw------- 1 root sd, 0 Oct 18 12:34 /dev/sd0a I can see it now: /etc/devcap will describe what these things mean. Then, someday, when two characters is simply not enough, we'll have to bite the bullet and go to /etc/devinfo, complete with the `dic' devinfo compiler. Steve :-) -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl --------Nancy Reagan on Dukakis for Pres: "Just say hohoho"--------
henry@utzoo.uucp (Henry Spencer) (11/08/88)
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
andrew@frip.gwd.tek.com (Andrew Klossner) (11/09/88)
[]
"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."
Think about diskless nodes with devices. The /dev file must live on
the server, so it's a BIG convenience if the major number is uniform
across all Suns. You could work around it, sure, but why introduce
such confusion?
-=- Andrew Klossner (uunet!tektronix!tekecs!frip!andrew) [UUCP]
(andrew%frip.gwd.tek.com@relay.cs.net) [ARPA]daveb@geaclib.UUCP (David Collier-Brown) (11/09/88)
> 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 ... From article <1988Nov7.190335.17023@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): | 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. Actually allowing one's supplier to preassign major numbers can lead to some very non-nice situations: I recently had a scanner fail because it was installed as device number 43 (on SunOS 3.5), instead of the usual 40 (as was used under 3.0..3.4). This tends to imply that some [expletive deleted] failed to use the device name, and instead used a hard-coded magic number. All it takes is two errors of that type and we're back with OS/360 and "you must use x'99.44/100' or it won't come clean. No two devices may use this number". --dave (why should I hand-craft a cdevsw, ANYWAY?) c-b 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... -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | HE's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
honey@mailrus.cc.umich.edu (peter honeyman) (11/09/88)
Andrew Klossner writes: >The /dev file must live on >the server, so it's a BIG convenience if the major number is uniform >across all Suns. correct me if i'm wrong, but isn't the <major, minor> manufactured by the client? <255, index-in-mnttab>? peter
henry@utzoo.uucp (Henry Spencer) (11/10/88)
In article <10589@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: >Think about diskless nodes with devices. The /dev file must live on >the server, so it's a BIG convenience if the major number is uniform >across all Suns. You could work around it, sure, but why introduce >such confusion? Because you want to minimize the number of major device numbers? That was one of my points, if you recall: unique major numbers are an administrative convenience, but if you are short of major numbers, all of a sudden it's not so convenient any more. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
guy@auspex.UUCP (Guy Harris) (11/10/88)
>>The /dev file must live on the server, so it's a BIG convenience if >>the major number is uniform across all Suns. > >correct me if i'm wrong, but isn't the <major, minor> manufactured >by the client? <255, index-in-mnttab>? The "st_dev" is manufactured by the client, in the fashion you indicate (more-or-less - I think it may be different in 4.0 so that multiple distributed file systems can be supported); however, the "st_rdev", which is what we're talking about, isn't manufactured by the client - major/minors for special files living on a server are interpreted in the same way as if they were local to the client (literally - the "specfs" code handles special files, regardless of whether the special file is gotten locally or over NFS).
peter@ficc.uu.net (Peter da Silva) (11/11/88)
So, what is the problem with just making dev_t bigger? Is there some magic code out there that would be hurt by making it 32 bits wide? -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
daveb@geaclib.UUCP (David Collier-Brown) (11/12/88)
From article <422@auspex.UUCP>, by guy@auspex.UUCP (Guy Harris): [ re major/minor numbers] |>correct me if i'm wrong, but isn't the <major, minor> manufactured |>by the client? <255, index-in-mnttab>? | | The "st_dev" is manufactured by the client, in the fashion you indicate | (more-or-less - I think it may be different in 4.0 so that multiple | distributed file systems can be supported); however, the "st_rdev", | which is what we're talking about, isn't manufactured by the client - | major/minors for special files living on a server are interpreted in the | same way as if they were local to the client (literally - the "specfs" | code handles special files, regardless of whether the special file is | gotten locally or over NFS). That sounds suspiciously like someone forgot that the mapping was going to be many-to-many and let it be one-to-one for the st_rdev. --dave c-b Any problem in computer science can be solved by using one more level of indirection -- attributed to Morven Gentleman, Waterloo. -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | HE's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
guy@auspex.UUCP (Guy Harris) (11/12/88)
>So, what is the problem with just making dev_t bigger? Is there some magic >code out there that would be hurt by making it 32 bits wide? It's mostly a binary-compatibility issue, not a source-compatibility issue.