From owner-freebsd-hackers Mon Jun 3 11:19:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA07884 for hackers-outgoing; Mon, 3 Jun 1996 11:19:58 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA07879; Mon, 3 Jun 1996 11:19:56 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25256; Mon, 3 Jun 1996 11:13:56 -0700 From: Terry Lambert Message-Id: <199606031813.LAA25256@phaeton.artisoft.com> Subject: Re: PR conf/1270 To: matt@lkg.dec.com (Matt Thomas) Date: Mon, 3 Jun 1996 11:13:56 -0700 (MST) Cc: bde@zeta.org.au, gpalmer@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199606021716.RAA18960@whydos.lkg.dec.com> from "Matt Thomas" at Jun 2, 96 05:16:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >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.