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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.02.14 at 11:07, Olaf Hering <olaf@xxxxxxxxx> wrote:
> On Fri, Feb 07, Jan Beulich wrote:
>> >>> On 07.02.14 at 09:32, Olaf Hering <olaf@xxxxxxxxx> wrote:
>> > 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.

"No" to the question. Dom0, without any console= and xencons=,
always writes _both_ ways (unless - under EFI only - it detects that
there's RAM at address 0xA0000), no matter whether this actually
ends up being visible anywhere.

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

Yes, I agree that there likely needs to be another change here.
I'm just not certain yet which way this should be done.

Jan



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