The following reply was made to PR port-xen/40675; it has been noted by GNATS.
From: Juergen Hannken-Illjes <hannken@xxxxxxxxxxxxxxx>
Cc: Christoph Egger <Christoph_Egger@xxxxxx>
Subject: Re: port-xen/40675: Xen 3.3: guest serial console not functional
Date: Fri, 20 Feb 2009 16:48:54 +0100
On Fri, Feb 20, 2009 at 04:38:10PM +0100, Christoph Egger wrote:
> > On Fri, Feb 20, 2009 at 02:56:51PM +0100, Christoph Egger wrote:
> > >
> > > Nope, that doesn't fix it.
> > Did you try it out?
> Yes. Sorry, I was too fast. I thought that doesn't fit with
> unix98 vs. BSD ptys.
> I tested it on Linux, too. It works there, too.
> I can only send patches upstream which don't break Linux.
So my patch broke Linux?
> > I had the problem described in this PR
> > on an amd64, running NetBSD-5.0_RC2 with xentools33 (2008Q4)
> > and it disappears with my patch. I printed the terminal
> > attributes after openpty() and they were garbage on the first
> > console, valid on the second etc.
> When openpty() returns garbage, isn't it broken then?
Openpty() gets garbage in (uninitialized attributes MODIFIED by cfmakeraw()).
It sets the slave to the attributes requested.
> > This just hides the bug. We create a pty pair with random
> > attributes, close the slave so these attributes disappear and
> > hope the slave will be reopened and initialized.
> And this happens on second console then ?
The initialization will come from xenconsole (init_term(spty, ...)).
This looks racey ...
Juergen Hannken-Illjes - hannken@xxxxxxxxxxxxxxx - TU Braunschweig (Germany)