pty attr race/issue

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

Hi,
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
happening:

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
  xenconsoled.
4 xenconsole sets the pty slave to cfmakeraw(), and things go back to
  normal.

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.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--