On Wed, 2006-09-06 at 10:18 +0100, Steven Smith wrote:
> > On Mon, 2006-09-04 at 10:02 +0100, Steven Smith wrote:
> > > 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.
That's what I thought as well.
> > > 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.
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
> > 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.
Yep -- one step at a time. And I've got it on my todo list for after
the xenfb stuff is merged
Jeremy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home