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"
right?
> 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
UI.
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel