--Ycz6tD7Th1CMF4v7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 11, 2004 at 07:28:54PM -0600, Eric Haszlakiewicz wrote:
> 	Actually, it sounds like even if you need to open a pty by name
> you can get rid of /dev/tty?? since those will automatically show up
> in /dev/pts/, right?
>=20
> 	When would you need to refer to a pty by name?  Does it actually
> work to have two different processes sitting with the master side open?

Steve's ircomm example is one case, screen attaches are another
(multiple sessions running), perhaps some ppp-over-ssh or similar
setups might be another.  But yes, these all refer to the pts half and
will be nodes in ptyfs.

Having the master sides be accessible statically rather than via a
cloning device has been a recipe for race conditions and security
problems (and just unnecessary complexity in allocation and selection
code, too).  This eliminates a whole set of potential "squatting"
attacks.

Real tty's for serial ports and so on don't have this split
personality, and this makes ptys much more like those, while handling
their dynamic appear-and-disappear nature.

I can't think of any cases of needing to share access to the master
node between processes, at least none that wouldn't be better and more
safely handled via things like fd passing regardless. I can think of
cases where an admin might need to forcibly revoke or otherwise kick a
stuck master to solve an application bug - but that can be found via
the pts node if need be. I wonder if Thor was thinking of a case where
it would be useful to have the pts node unlinked and invisible as
well?

Anyway, this is a welcome improvement (though ptmx was the biggest
single gain, rather than the convenience of ptyfs).  There are other
cases where the same model of cloning master and dynamically created
entity nodes could be a win: one we already discussed is multi-voice
opens of audio devices (though they perhaps only need the cloning
part).

--
Dan.
--Ycz6tD7Th1CMF4v7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFBlBuTEAVxvV4N66cRAotXAJ9JkEocWbg/YnsTSJhMZYW9j7Zi+gCfRSvN
BVFVnox1dkN0w5sSbvwuq64=
=yX9N
-----END PGP SIGNATURE-----

--Ycz6tD7Th1CMF4v7--