jason@violet.Berkeley.EDU (Jason Venner) (07/29/87)
As we get larger and larger machines, the naming conventions for tty's
and ptys are getting pushed beyond their design specs. We have a
couple of machines here that need more than 256 pty's, and more than
100 tty's.
At this point, every program that grabs a pty, has a pty grabbing
routine hard coded in, they usually stop after q, or r. If you are a
binary only site (or run ultrix) you're %^&*ed.
It is time to rethink the naming conventions for devices.
For one, /dev is getting ridiculously large, and open times are growing.
On BSD:
The major & minor number needs to be changed, 8 bits for each is not enough.
-------------
Changing the declaration of dev_t to an unsigned long from a short,
and modifying major() & minor() in types.h, and deleting some of the
fill space in the stat structure (stat.h) would allow for more
major/minor devices without complicating life too much
making directorys in /dev and putting files in there would solve
several problems:
ie:
/dev/pty/....
/dev/ttyp/...
/dev/ra/...
/dev/rra/...
1: it would speed up accesses through /dev
2: pty numbers could just be a numerical sequence in the directory
ie: 0 1 2 3 4 5 6 7 8 9 10 11
In this manner, you just access up until you miss a number
to get all the ptys, no hard coded pty
Jason Venner
UUCP {tektronix,dual,sun,ihnp4,decvax}!ucbvax!jade!jason
New style jason@jade.berkeley.edu
ARPA | CSNET jason%jade@Berkeley.ARPA
BITNET jason@ucbjade.BITNETchris@mimsy.UUCP (Chris Torek) (07/29/87)
In article <8550@brl-adm.ARPA> jason@violet.Berkeley.EDU (Jason Venner) writes: >As we get larger and larger machines, the naming conventions for tty's >and ptys are getting pushed beyond their design specs. ... >At this point, every program that grabs a pty, has a pty grabbing >routine hard coded in, they usually stop after q, or r. If you are a >binary only site (or run ultrix) you're %^&*ed. An amusing thing about these programs is that most *also* have a stat() call so as to stop as soon as there are no more ptys. Hence the hardcoded stop point is entirely unnecessary. >It is time to rethink the naming conventions for devices. (`Rethink' is a horrible word. But I use it at times too....) >Changing the declaration of dev_t to an unsigned long from a short, This is quite obviously planned. I cannot say when CSRG will in fact do it, but all the hooks are there. >making directorys in /dev and putting files in there would solve >several problems: We already have /dev/fd/ here, and I plan to create /dev/disk/ and /dev/tape/ (but it never seems urgent). /dev/tty/ is more troublesome (too many programs `know' about tty names). Even so, finding a free pair of ptys is too hard; 4BSD needs a general resource manager, with which one can simply say `call this phone number' or `I want a pty master and slave' or `I would like to write to joe'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/30/87)
In article <8550@brl-adm.ARPA> jason@violet.Berkeley.EDU (Jason Venner) writes: >It is time to rethink the naming conventions for devices. Exactly right. >The major & minor number needs to be changed, 8 bits for each is not enough. Do you really have multiplexors that have more than 256 channels? Each multiplexor could be a separate major device, aliased in the devsw. >making directorys in /dev and putting files in there ... This is one of my favorite ideas. However, it does impact code such as "ps" that "knew" the old scheme. By the way, AT&T did this already for magtape and disk devices.
dce@mips.UUCP (David Elliott) (07/30/87)
In article <8550@brl-adm.ARPA> jason@violet.Berkeley.EDU (Jason Venner) writes: > >Changing the declaration of dev_t to an unsigned long from a short, >and modifying major() & minor() in types.h, and deleting some of the >fill space in the stat structure (stat.h) would allow for more >major/minor devices without complicating life too much While I agree with your problem statement and scheme for directories (and would also like to see a library routine for getting a useable pty name), the above statement is not completely true. You see, we really can't tell how much software out there relies on the sizes of major and minor device numbers. The brain that invented the cpio format in AT&T Unix never thought that these sizes might change, so it has device numbers inside of it (I implemented a fix for this in UTek, but I can't get to it). I suggest using more major numbers for ptys and ttys before changing the size of device numbers. -- David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce
scott@altos86.UUCP (Scott A. Rotondo) (08/05/87)
In article <6200@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <8550@brl-adm.ARPA> jason@violet.Berkeley.EDU (Jason Venner) writes: >>making directorys in /dev and putting files in there ... > >This is one of my favorite ideas. However, it does impact code such as "ps" >that "knew" the old scheme. I'm not certain I see why this has to impact code that knows about the old scheme. Is there any reason you can't have both? Just make the new directories contain links to the regular /dev entries. Now you get the advantage of the faster searches while allowing old code to work exactly as it always did. -- Scott -- =============================================================================== Scott A. Rotondo, Altos Computer Systems (408) 946-6700 ...!ucbvax!sun!altos86!scott ...!ihnp4!elxsi!altos86!scott
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/08/87)
In article <382@altos86.UUCP> scott@altos86.UUCP (Scott A. Rotondo) writes: >I'm not certain I see why this has to impact code that knows about the old >scheme. Is there any reason you can't have both? Yes, the original poster had too many lines for the old scheme. Also, presumably one is trying to fix things, not complexify them.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/08/87)
In article <382@altos86.UUCP> scott@altos86.UUCP (Scott A. Rotondo) writes: [talking about putting devices in subdirectories under /dev for speed] >> >>This is one of my favorite ideas. However, it does impact code such as "ps" >>that "knew" the old scheme. > >Just make the new >directories contain links to the regular /dev entries. There's a trap here that I have fallen into when using UUCP and related programs both under Microport System V/AT (Release 2 equivalent) and under 4.3BSD. In some cases a lock file is created whose name is based on the name of the device being used. If the device has multiple names, you may find that the lock file is created by one name, but when the program exits, it tries to remove the lock file by another name and fails. I suspect this happens because some programs use ttyname(3) to find the name of their controlling terminal, and also use the device name obtained from L.sys, at different times. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
james@cantuar.UUCP (J. Collier) (08/13/87)
In article <7757@mimsy.UUCP> Chris Torek (chris@mimsy.UUCP) writes: > ...... Even so, finding a >free pair of ptys is too hard; 4BSD needs a general resource manager, >with which one can simply say `call this phone number' or `I want >a pty master and slave' or `I would like to write to joe'. > I have developed a pseudo-terminal server and a couple of client library routines for handling the allocation of pseudo-terminals. The library routines use unix-domain IPC to acquire and relinquish master/slave pairs from the server - the master fd is passed in the access rights field to avoid races. Since the server runs as root it can also handle tty ownership and utmp updating if requested. Client processes are periodically checked and privileges are revoked if they have died. The system is somewhat hairy in places, especially in its attempts to provide a reasonable level of security. This may not be justifiable, given that tty security is still a bad joke anyway (4.3BSD). It also contains a certain amount of borrowed code (utmp stuff & other bits from John Bruner's "uw"). Perhaps someone would be interested in writing a similar system suitable for public release. ------------------------- James Collier (james@cantuar.uucp / {watmath,munnari,mcvax}!cantuar!james) Computer Science Dept., University of Canterbury, Christchurch, New Zealand.
mouse@mcgill-vision.UUCP (der Mouse) (08/24/87)
In article <382@altos86.UUCP>, scott@altos86.UUCP (Scott A. Rotondo) writes: > In article <6200@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >> In article <8550@brl-adm.ARPA> jason@violet.Berkeley.EDU (Jason Venner) writes: >>> [...] making directorys in /dev and putting files in there [...] >> This is one of my favorite ideas. However, it does impact code such >> as "ps" that "knew" the old scheme. > I'm not certain I see why this has to impact code that knows about > the old scheme. Is there any reason you can't have both? Just make > the new directories contain links to the regular /dev entries. Now > you get the advantage of the faster searches while allowing old code > to work exactly as it always did. Unfortunately, you don't. The whole problem is that /dev is a large directory, ie, has many entries. If you don't get rid of the entries the current scheme requires, the problem won't go away. Just creating a subdirectory with alternate names for them won't do. That is, looking up /dev/tty/p3 is no faster than looking up /dev/ttyp3, since both of them have to search through /dev. The win occurs when /dev/ttyp3 doesn't exist and hence /dev is smaller, making searches through it faster. You could probably work a bit to arrange that the subdirectories appear first in /dev, but ensuring it stays that way would be harder. (What we need is a directory lookup scheme that's better than linear search. Anybody feel ambitious? :-) der Mouse (mouse@mcgill-vision.uucp)
barmar@think.COM (Barry Margolin) (09/04/87)
In article <868@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >That is, looking up /dev/tty/p3 is no faster than looking up >/dev/ttyp3, since both of them have to search through /dev. How about putting them in a directory that isn't a subdirectory of /dev, e.g. /ttys/p3? --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
scott@altos86.UUCP (09/04/87)
I wrote: >> I'm not certain I see why this has to impact code that knows about >> the old scheme. Is there any reason you can't have both? Just make >> the new directories contain links to the regular /dev entries. Now >> you get the advantage of the faster searches while allowing old code >> to work exactly as it always did. der Mouse responds: >That is, looking up /dev/tty/p3 is no faster than looking up >/dev/ttyp3, since both of them have to search through /dev. The win >occurs when /dev/ttyp3 doesn't exist and hence /dev is smaller, making >searches through it faster. Now wait a second. There is no reason that the tty subdirectory has to appear under /dev. You could easily make it /Dev/tty/p3 or something similar and then you *would* get the faster searches without breaking old code. -- Scott -- =============================================================================== Scott A. Rotondo, Altos Computer Systems (408) 946-6700 ...!ucbvax!sun!altos86!scott ...!ihnp4!elxsi!altos86!scott
greywolf@unisoft.UUCP (R-O-A-N, diacritical (two dots) over the O.) (09/09/87)
>>That is, looking up /dev/tty/p3 is no faster than looking up >>/dev/ttyp3, since both of them have to search through /dev. I don't believe that is the case. Looking up /dev/ttyp3 has to look through /dev (i.e. opendir("/dev"); look(); puke(); etc...) which contains things like tty??, [r]hp??, [r]ud??, pty??, null, and other such devices, whereas putting all the ttys in /dev/tty (and the like), it only has to look at a fraction of what it would look at if everything is in /dev directly with no subdirectories. To the best of my knowledge it doesn't involve nearly as much time to opendir("/foo/bar") and search for component blurfl as it would doing opendir("/foo/barblurfl") with everything on one single level. It isn't as though you have to call a seekdir on /dev to find directory (/dev)/tty. I could be wrong... Of course, what happens to /dev/tty (the device) if it were to be made into a directory? Would we use /dev/tty/tty or what? ------------------------------------------------------------------------------- /harley/davidson: Mount device busy. ------------------------------------------------------------------------------- NOTA BENE: The views expressed in this posting are NOT those of Unisoft, They are those of the poster, who may not be aware of everything the company is doing. Roan Anderson UniSoft Corporation ...{ucbvax,amdahl,sun}!unisoft!greywolf (415) 420-6400
allbery@ncoast.UUCP (Brandon Allbery) (09/12/87)
As quoted from <543@unisoft.UUCP> by greywolf@unisoft.UUCP (R-O-A-N, diacritical (two dots) over the O.): +--------------- | Of course, what happens to /dev/tty (the device) if it were to be | made into a directory? Would we use /dev/tty/tty or what? +--------------- The early Plexus SVR2.2 manuals suggest that AT&T at least toyed with the idea of renaming "/dev/tty" to "/dev/termio" in order to accomplish this. I would suggest that changing the names of tty devices to /dev/termio/nnn would be less likely to cause massive confusion. -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> All opinions in this message are random characters produced when my cat jumped (-: up onto the keyboard of my PC. :-)
henry@utzoo.UUCP (Henry Spencer) (09/16/87)
> (What we need is a directory lookup scheme that's better than linear > search. Anybody feel ambitious? :-) I looked at hashed directories a few years ago and couldn't come up with a scheme that really satisfied me... but I didn't try enormously hard. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry