bitkeeper revision 1.1236.42.1 (42422fb2SvqEyBwXAZf3p2BJS-gfBA)

If Xen is told to use a serial console via a com1= or com2= directive
on the Xen command line, it now hides that particular UART from dom0.

This means that it's now safe to enable the 8250 driver in the Linux
config. If Xen has been told to use com1, the dom0 linux kernel will
not see /dev/ttyS0, but will see ttyS1,S2 etc if they are present,
enabling them to be used for mice, modems, printers etc.

Unfortunately, the 8250 driver will register itself for a ttyS even if
that particular UART isn't present. This is really annoying, as it 
prevents the 'xencons' driver registering itself as ttyS0 even though
the 8250 won't see ttyS0 as present if Xen is using com1. This
prevents us from enabling 8250 in the default kernel config, as it 
will change current behaviour. 

If you want to use 8250 and xencons, the trick is to tell xencons to
grab a high numbered ttyS port that the 8250 driver will have left
alone. For example, put "xencons=ttyS31" on the Linux command line.
You'll then be able to edit /etc/inittab to add an entry for a 
getty on ttyS31 if you want to be able to log in on the serial console
that is being shared with Xen.

If anyone knows a way of cleanly kicking the 8250 driver off a
particular char minor then please let me know!

 

1 files changed, 2 insertions, 0 deletions

diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 60fd64186d..4d33ddb17b 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -50,6 +50,8 @@ unsigned char irq_serial_getc(int handle);
 
 void serial_force_unlock(int handle);
 
+void serial_endboot(void);
+
 #endif /* __XEN_SERIAL_H__ */
 
 /*