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 console cleanups [5/5]

To: Jeremy Katz <katzj@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Paravirt framebuffer console cleanups [5/5]
From: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Date: Wed, 6 Sep 2006 10:18:32 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>, sos22@xxxxxxxxxxxxx
Delivery-date: Wed, 06 Sep 2006 02:19:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1157472707.7571.85.camel@xxxxxxxxxxxxxx>
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: <1157227140.11059.45.camel@xxxxxxxxxxxxxx> <20060904090228.GE4812@xxxxxxxxx> <1157472707.7571.85.camel@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> On Mon, 2006-09-04 at 10:02 +0100, Steven Smith wrote:
> > > diff -r c859588adc5e -r 72582b968445 
> > > linux-2.6-xen-sparse/drivers/char/tty_io.c
> > > --- a/linux-2.6-xen-sparse/drivers/char/tty_io.c  Sat Sep 02 15:31:29 
> > > 2006 -0400
> > > +++ b/linux-2.6-xen-sparse/drivers/char/tty_io.c  Sat Sep 02 15:32:38 
> > > 2006 -0400
> > 
> > It looks to me like this patch makes tty_io.c identical to the
> > upstream version.  Is this correct?
> Yep -- so actually could be removed from the sparse tree.  I'm usually
> working in a non-sparse tree, so the diff is more relevant.
Ack.

> > > diff -r c859588adc5e -r 72582b968445 
> > > linux-2.6-xen-sparse/drivers/xen/console/console.c
> > > --- a/linux-2.6-xen-sparse/drivers/xen/console/console.c  Sat Sep 02 
> > > 15:31:29 2006 -0400
> > > +++ b/linux-2.6-xen-sparse/drivers/xen/console/console.c  Sat Sep 02 
> > > 15:32:38 2006 -0400
> > > @@ -663,6 +663,20 @@ static int __init xencons_init(void)
> > >   printk("Xen virtual console successfully installed as %s%d\n",
> > >          DRV(xencons_driver)->name, xc_num);
> > >  
> > > +        /* Don't need to check about graphical fb for domain 0 */
> > > +        if (is_initial_xendomain())
> > > +   return 0;
> > > +
> > > + rc = 0;
> > > + if (xenbus_scanf(XBT_NIL, "console", "use_graphics", "%d", &rc) < 0)
> > > +         printk(KERN_ERR "Unable to read console/use_graphics\n");
> > > + if (rc == 0) {
> > > +               /* FIXME: this is ugly */
> > > +        unregister_console(&kcons_info);
> > > +        kcons_info.flags |= CON_CONSDEV;
> > > +        register_console(&kcons_info);
> > > + }
> > > +
> > Could you pull the setting of CON_CONSDEV into xen_console_init and
> > avoid this weirdness?
> Nope -- when consoles are registered, we don't have enough
> infrastructure to check xenbus to see if console/use_graphics is set or
> not
That's a pity.

> > This whole passage is a little peculiar, in that you're only going to
> > do anything if use_graphics is disabled.  I'd expect that just leaving
> > the current behaviour alone would be the correct thing to do in that
> > case.
> > 
> > Also, why do you need to set CON_CONSDEV at all?
> 
> Otherwise, you don't get kernel console messages.
Why not?  None of the other console drivers seem to need to set it
explicitly, and it seems like it would break setting console=blah on
the kernel command line.

It also strikes me as very odd that you need to do this iff
use_graphics is switched off.

> Realistically, I think the better longer-term answer is to create an
> early xenconsole -- then, when we do this later initialization, we can
> deregister the early console and do the right registration for the
> "real" console.  This mirrors pretty closely what's done on a few other
> arches
Agreed, but not in this patch series.

Steven.

Attachment: signature.asc
Description: Digital signature

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