Skip site navigation (1)Skip section navigation (2)
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>