Date: Mon, 3 Jun 1996 11:13:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: matt@lkg.dec.com (Matt Thomas) Cc: bde@zeta.org.au, gpalmer@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: PR conf/1270 Message-ID: <199606031813.LAA25256@phaeton.artisoft.com> In-Reply-To: <199606021716.RAA18960@whydos.lkg.dec.com> from "Matt Thomas" at Jun 2, 96 05:16:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >Anyone know why the patch in the PR SHOULDN'T be applied? (apart from > > >the fact it makes /etc/ttys massive :-/ ) Perhaps the first 128 pty's > > >should be defined, leaving a note that you have to define the others > > >if you want to have more? > > > > It should probably be applied (after testing :-) to -stable, but for > > -current someone should work on how this is going to work with devfs > > when there will be an unlimited number of ptys. > > > > Each additional statically configured pty currently costs 252 bytes > > for the tty struct alone, not about 128 bits as guessed in the PR. > > A default of 32 would still be reasonable. > > That's the problem right there. The tty structure (and anything else > required by the pty driver) should be dynanmically allocated on first > open and closed on last close. Then keep a list of pointers to softc > structures inside the pty driver indexed by minor number. It's even > releatively make this list dynamic as well so it grows as it needs to. > > I implemented something similar for Digital UNIX when I did the it's > initial LAT implementation. Under ULTRIX, I was quite sick & tired > of having to rebuild the kernel for a more lat devices. So in Digital > UNIX I got the infrastructure changed to make it possible. If you > wanted more LAT ttys, all you had to do is make the /dev entries for > them. > > Looking at FreeBSD, it looks like it could support doing the above > today rather easily. I have been considering this very problem for some time in the context of devfs. I believe what is wanted is a cloning pty driver. This is a rather trivial thing to implement, given a working devfs, or a near-impossible thing to implement, without devfs. There is also the issue of pty acquisition and relinquishing to be dealt with; the open->close 1->0 reference on the master should probably revoke the slave and propagate SIGHUP. This is somewhat complicated by the fact that BSD's "POSIX" revocation/SIGHUP code is broken, as far as most applications are concerned. The acquisition is, by far, the largest problem, since it implies a difference from other systems. The best we can hope for in this regard, IMO, is to adopt an existing cloning model to reuse the allocation code; AIX seems to be the one, unless we encapsulate our own in one of the two common pty access libraries out there. This is a problem that has been discussed at length on -current in the context of devfs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606031813.LAA25256>