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

[Jeremy Katz <katzj@xxxxxxxxxx>]

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