[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pty attr race/issue
while working on xen3 xenconsole/xenconsoled I ran into a difference
between the linux way of doing pty attributes and ours. On linux setting
cfmakeraw() on the master side seems to be enough (especially to kill echo),
while I also had to set it on the slave side of the pty on NetBSD.
This didn't get things completely clean, as we could still see some domU boot
lines being echoed back to the domU when the console was connected.
When Juergen Hannken-Illjes added pygrub support he also debugged the spurious
echo a bit further. He found that after xenconsoled sets the master side of
the pty to cfmakeraw(), it gets back to echo without apparent action
on the master side. I did some more tests, and here's what I think is
1 when a new domU is created, xenconsoled notices it, open /dev/ptmx to get
a new pseudo-tty, sets the master side O_NONBLOCK and cfmakeraw(), writes
the name of the tty slave to the xen store and includes the new
pty master in its select loop. At this point, it keeps characters coming
from the domU in its own buffer, as the pty slave is closed and
select will not say the pty master is ready for write (or read).
2 xenconsole sarts, and opens the pty slave
3 immediatly xenconsoled start writing to the pty master, as it has data
ready in its private buffer and select returned the pty master as
ready for write. At this point the pty master is back to ECHO.
at the next select loop the pty master will be ready for read, and
xenconsoled will read back the data it has just written (and send them
back to the domU kernel). If the domU console device is also in ECHO
mode, the data will ping-pong between the domU's kernel and
4 xenconsole sets the pty slave to cfmakeraw(), and things go back to
Is there a way to avoid the race between 3 and 4 ? Making
the pty slave open not reset the pty attributes would be the best,
but I'm open to other suggestions. Checking the pty attributes in
xenconsoled before each write could work, but it's a gross hack and I'd
prefer to avoid it.
Manuel Bouyer, LIP6, Universite Paris VI.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |