Re: [Xen-devel] [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Olaf Hering <olaf@xxxxxxxxx>]

On Fri, Feb 07, Jan Beulich wrote:

> >>> On 07.02.14 at 09:32, Olaf Hering <olaf@xxxxxxxxx> wrote:
> > On Fri, Feb 07, Jan Beulich wrote:
> > 
> >> They question is what the intended behavior here is: I'd generally
> > 
> > In my opinion dom0 is just a child of Xen, which should follow the rules
> > of the parent. If Xen is configured to have its console on serial then
> > the default of dom0 should be to follow just that. Appearently its just
> > a matter of correctly using xvc0.
> > 
> > I'm not sure what the gain would be to have Xen on serial and dom0
> > somewhere else, and enforcing the need of a console= cmdline option to
> > point dom0 also to serial. Thats just doing things twice.
> 
> That's a fair point, but leaves aside the case of Xen _not_ using
> the serial console. Dom0 has no way to know, and hence would
> still push output there, not knowing that it ends up no-where.

You mean no Xen console= option implies that dom0 writes no-where? I
would think dom0 will use the graphics card in this case to send its
output.

> Also the "follow the rules of the parent" already doesn't apply for
> the VGA console case, where Dom0 makes its own decision too
> (and it's for that reason that Xen needs to stop sending data to
> the VGA in order to not interfere). Hence I'm not sure that
> argument really counts.

The details about driving a certain hardware dont really matter. I think
the important part is "goes to the wire" vs. "goes to the monitor". 

I think the bug is that register_console("xvc") is called without a
preceeding add_prefered_console, which with current kernels means a
second entry in /proc/consoles. This in turn lets systemd spawn a login
for that.

Somehow I think the rules have changed since 2.6.18. I will have a look
at this now.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel