What do you think ?: How should pseundo terminals behave ...
Martin Blapp
mb at imp.ch
Tue Sep 26 02:34:07 PDT 2006
... if there is no slave and master anymore, both sides are closed (for example
after we did type exit in our term) and we open a slave and write something to
the closed pty ?
What we currently do:
If we have no slave and master ttypX ttytX anymore and we try to write to the
ttypX like:
echo "BLUBBER" > /dev/ttypX
We get currently blocked in ptsopen(). That's ok so far.
But after we ssh into the box again, THE SAME ! tty gets opened too,
leading to a tty livelock for 5 minutes.
Sometimes we gets then EOPNOTSUPP when the writer gets aborted, sometimes
we get two ptsclose(). After we exit this pty the refcounts are off by one, we
make one ttyrel() too much so the tty structure gets completly freed in ttyrel()
and the next ptsopen/ptcopen panics our box this is FreeBSD6 behaviour. With my
fixes CURRENT doesn not panic anymore, but it leaks ptys.
So how should ptys behave ?
1.) Block until the tty is really opened again and there is
a master available again. Then write to the freshly opened
pty. (not easy to do)
2.) Block forever since the tty will not be reopened anymore since
we leak ptys.
3.) Detect that there is no master around anymore and
return ENXIO:
# echo "BLUBBER" > /dev/ttypX
# /dev/ttypX: Device not configured
(easy to do, i've got a fix. IMHO this is the best thing to
do. This allows fast error recovery in case the master
has been gone away)
4.) Keep the current behaviour, leak terminals or panic.
(the simplest thing to do. Let's keep the bugs)
Please vote for any of those choice. Thank you for your
participation.
Martin
Martin Blapp, <mb at imp.ch> <mbr at FreeBSD.org>
------------------------------------------------------------------
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: <finger -l mbr at freebsd.org>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
------------------------------------------------------------------
More information about the freebsd-current
mailing list