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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Default serial console to BAUD_AUTO

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Default serial console to BAUD_AUTO
From: John Levon <john.levon@xxxxxxx>
Date: Mon, 24 Sep 2007 20:40:43 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 24 Sep 2007 12:39:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C31DBC8A.DF66%Keir.Fraser@xxxxxxxxxxxx>
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: <20070924175802.GA8669@xxxxxxxxxxxxxxxxx> <C31DBC8A.DF66%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Mon, Sep 24, 2007 at 07:12:10PM +0100, Keir Fraser wrote:

> > Indeed, this has changed in xen-unstable compared to 3.0.4, my apologies. So
> > with my patch you'll automatically get serial console output in 
> > xen-unstable,
> > regardless of console=com1
> The behaviour was exactly the same in 3.0.4. In fact the current behaviour
> has existed forever, pretty much.

It appears I was being misled by the init_console() code.

> Actually another reason to not change the current behaviour is that it will
> also lock out dom0 from getting at COM1 and COM2. Because any serial ports
> that ns16550.c knows about get removed from dom0's io permissions.
> I expect we could rework some stuff to get some slightly more sensible
> defaults to emerge (e.g., console=...com1... could imply that com1 should be
> grabbed by Xen with sensible defaults), but it's more work than your
> one-line patch

Clearly I didn't look at this code closely enough, but when you say more work,
you mean:

-#define OPT_CONSOLE_STR "com1,vga"
-#define OPT_CONSOLE_STR "vga"


> and, really, you can just put 'com1=auto' on your command
> line to get the same effect and then noone gets surprised by Xen locking
> down serial ports when com1/com2 does not appear on their Xen command line.

Fair enough, we should not use the serial console by default (although at least
Solaris will feed output through HYPERVISOR_console_io if Xen's already grabbed
it). However, I don't think that the current *code* (whereby the serial console
gets disabled as a side effect of not setting BAUD_AUTO, and OPT_CONSOLE_STR
does not do what it appears to do) is readable or maintainable. Can we please
make the intention of the code clear?

Neither do I think that forcing users to unnecessarily set "com1=auto" is good


Xen-devel mailing list