Re: [Xen-devel] [PATCH] Fix xenconsole's "Could not read tty from store"

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Tue, Dec 18, 2007 at 06:18:16PM +0000, Samuel Thibault wrote:

> > > > > +     if (tcgetattr(master, &term) < 0) {
> > > > > +             err = errno;
> > > > 
> > > > Please use the slave not the master. It doesn't matter on Linux but it's
> > > > critical on Solaris.
> > > 
> > > What is the Solaris reason for this?  It really looks we can't afford
> > > closing the slave end on Linux (hence leak it) or not open it at all
> > > (and then we can't tcgetattr on it).
> > 
> > On Linux, both ends of a pty act like a pseudo-terminal and you can do
> > term-like things on both ends (and there's apparently small variations
> > in the effect they have). This is not true on STREAMS-based systems. In
> > particular, you have to push the "ptem" module before you can use any of
> > the tcget/setattr() functions (look at openpty()).
> 
> I'm precisely reading that part of the sun manual thanks to google, yes
> :)
> 
> Can't we push those modules on such systems?

I do - on the slave. It's nonsensical to push it onto the master, I
think. In fact it's dubious doing this tcsetattr() /at all/ - I would
have thought that xenconsole is the right place to be doing that.

> > I'm working on a new version of the patch that just keeps the slave open
> > (without leaking it) on both platforms - I think this should cover these
> > differences sufficiently.
> 
> Well, there should be no reason to open the slave part at all, actually.

openpty() always gives us a slave fd so it's already open. There's no way
on Linux to not busy-loop without keeping a slave fd open, since you set
non-blocking on the master fd. Additionally, if we were to close the
slave fd, then we have to re-introduce the code that checks for a read
of zero for Solaris.

> To my understanding, from the server side tcsetattr should only be
> performed on the master side (with effect on the slave side too).

See above, I don't quite follow why it's necessary at all.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel