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
|
Home