Re: pty attr race/issue

[christos%astron.com@localhost (Christos Zoulas)]

In article <20080307173359.GA17207%asim.lip6.fr@localhost>,
Manuel Bouyer  <bouyer%antioche.eu.org@localhost> wrote:
>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.

Why does xenconsole need to open the slave pty? Can't xenconsoled just
open it, set it up the way it wants, then exec xenconsole with fd 0, 1, 2
as the slave pty?

christos