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 1/2] PV framebuffer

To: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/2] PV framebuffer
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Fri, 17 Nov 2006 16:33:45 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, sos22@xxxxxxxxxxxxx
Delivery-date: Fri, 17 Nov 2006 07:33:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <87wt5yjffh.fsf@xxxxxxxxxxxxxxxxx> (Markus Armbruster's message of "Tue, 14 Nov 2006 15:01:06 +0100")
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: <87mz6zptr0.fsf@xxxxxxxxxxxxxxxxx> <20061112142034.GB2014@xxxxxxxxx> <87wt5yjffh.fsf@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
Markus Armbruster <armbru@xxxxxxxxxx> writes:

> Steven Smith <sos22-xen@xxxxxxxxxxxxx> writes:
[...]
>>> diff -rupN -x '*.orig' linux-2.6.16.29-xen/drivers/xen/console/console.c 
>>> linux-2.6.16.29-xen-vfb/drivers/xen/console/console.c
>>> --- linux-2.6.16.29-xen/drivers/xen/console/console.c       2006-09-29 
>>> 16:11:51.000000000 +0200
>>> +++ linux-2.6.16.29-xen-vfb/drivers/xen/console/console.c   2006-11-10 
>>> 09:43:37.000000000 +0100
>>> @@ -680,3 +712,17 @@ 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);
>>> +   }
>> I'm still not entirely sure I understand why this bit is necessary.
>>
>> From talking to katz@xxxxxxxxxx last time:
>>
>>> > > > > 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.
>>> > Nothing else sets it explicitly because it happens implicitly in the
>>> > console registration code for the first thing registered with
>>> > register_console().  Alternately, if you have a console=, then
>>> > register_console ensures that your console device has CON_CONSDEV set.
>>> > kernel/printk.c if you want to read all the gory details
>>> The intent of this code seems to be to make sure that CON_CONSDEV is
>>> definitely set on xenconsole if use_graphics is not set, yes?  But as
>>> far as I can see, if use_graphics is not set, xenfb should never call
>>> register_console(), and so this is all redundant.
>>
>>
>> I'm still just as unenlightened as I was then.  Plus, xen_console_init
>> should be called before any of the pvfb stuff anyway, since it's a
>> console_initcall and pvfb starts from a module_init, so it's doubly
>> redundant.
>
> Jeremy, could you elaborate?

Jeremy is buried alive in email right now.  This is what he wrote to
me, quoted with permission:

    The reason why this is needed is because the Linux console code is
    a mess.  xen_console_init _does_ get called earlier but dummycon
    gets initialized first and ends up as the primary console.  When
    the fb layer starts going, xenfb takes over from dummycon and it's
    the primary console.  All good if you're wanting the fb.  If
    you're _not_ though and you have it any of the VC stuff compiled
    into the kernel, then you need to reset xencons as the actual
    primary console dev.

    The better thing to do in the longer term is to actually have a
    xen_early_console along the lines of the ppc early console stuff
    (see viocons_early in drivers/char/viocons.c) so that you're doing
    a sane hand-off.  But the (reasonable, IMHO) consensus after the
    last cycle was to do that as a separate patch set as it's not
    fundamentally related to the pvfb stuff.

If I understand this correctly, the hack is required to make xencons
working when xenfb is compiled in but not active.

Since we let xend create the xenstore for the devices now, we can
check whether the frontend device is in xenstore here, and drop
console/use_graphics.  We could also conditionalize on
XEN_FRAMEBUFFER, but I doubt it's worth the bother.

[...]

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