WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Paravirt framebuffer use xvc as console [4/5]

To: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Paravirt framebuffer use xvc as console [4/5]
From: Jeremy Katz <katzj@xxxxxxxxxx>
Date: Wed, 06 Sep 2006 10:05:13 -0400
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>, sos22@xxxxxxxxxxxxx, Amos Waterland <apw@xxxxxxxxxx>
Delivery-date: Wed, 06 Sep 2006 07:05:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060906091738.GF3257@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1157227130.11059.44.camel@xxxxxxxxxxxxxx> <20060904090111.GB4812@xxxxxxxxx> <1157472719.7571.90.camel@xxxxxxxxxxxxxx> <20060906091738.GF3257@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2006-09-06 at 10:17 +0100, Steven Smith wrote:
> > > > This is the patch from Amos Waterland for the xenconsole to
> > > > use /dev/xvc0 instead of taking over ttys.  I've fixed a few places
> > > > which needed to check for XVC mode in addition to serial mode.  Also,
> > > > until LANANA responds with an official minor, I've adjusted it to use
> > > > char 250/187 (in the experimental range) as opposed to 204/187.
> > > > 
> > > > (Should be identical to this patch from last time)
> > > Does this have anything to do with the virtual framebuffer work, or
> > > does it stand alone?
> > It stands alone, but without it, the framebuffer bits get a little
> > confusing to actually try to have used as the console.
> What goes wrong?

xenconsole takes over ttys and although you can see the framebuffer with
the penguin and X will start, you can't actually use the framebuffer as
a console :-)

> > > > @@ -194,11 +209,17 @@ static int __init xen_console_init(void)
> > > >                 kcons_info.write = kcons_write_dom0;
> > > >         } else {
> > > >                 if (xc_mode == XC_DEFAULT)
> > > > -                       xc_mode = XC_TTY;
> > > > +                       xc_mode = XC_XVC;
> > > Not convinced we want to change the default until a little while after
> > > the rest of the patch gets merged.
> > The default *HAS* to be changed -- otherwise, the xvc console tries to
> > take over ttys (which is really really really wrong in the guest)
> So why have we survived this far without it?  If XC_TTY is completely
> broken, why not remove it completely?

We've survived this far because there isn't anything else which is
trying to use the console and this hack let people pretend they had
multiple vcs[1].  

Nuking it entirely is the right long-term answer, but giving people who
still depend on it an "out" for a little bit probably makes sense.
Although I could easily be convinced to just nuke it from orbit ;)

Jeremy

[1] Much in the same way that s390 does.. poorly ;-)


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