On Mar 23, 2005, at 9:10 PM, BitKeeper Bot wrote:
ChangeSet 1.1358, 2005/03/24 03:10:42+00:00,
iap10@xxxxxxxxxxxxxxxxxxxxx
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!
That isn't possible, though it has been a frequent feature request for
the Linux serial layer. Major 4 minor 64 is reserved for the serial
driver(s). Other drivers, even similar drivers, must get their own.
This is to be expected: the SCSI driver does not take over major 3
minor 0, even though SCSI is a block driver "like IDE".
There is plenty of precedent here. The drivers in drivers/serial hijack
the ttyS nodes, since serial ports are generally onboard and it's
almost unheard-of to have different types present. Drivers that do not
fit into the serial framework, however, need their own major. IBM
pSeries virtual console uses /dev/hvsi*. Cyclades uses /dev/ttyC*.
$(grep '"tty."' drivers/char) will show you more than you ever knew
existed... and they all use their own major number and device nodes.
I wrote drivers/char/hvsi.c, so I've been here before, and I'd
definitely recommend not trying to hijack serial (ttyS) nodes. It just
doesn't make sense: what does hardware flow control mean to a virtual
console? What about baud rate, parity, stop bits, IO port? Even worse,
all those ioctls like TIOCSERGETLSR ("get line status register") --
which ioctls can you return an error for, and which can you fake, and
what will you break when you fake it? Example from anaconda (Red Hat's
installer):
if (major(sb.st_rdev) != 3 && major(sb.st_rdev) != 136 &&
(virtpcon != NULL)){
if ((ioctl (0, TIOCLINUX, &twelve) < 0) &&
(ioctl(0, TIOCGSERIAL, &si) != -1))
flags |= LOADER_FLAGS_SERIAL;
}
Wouldn't want to break that. I wonder if we want LOADER_FLAGS_SERIAL
set or not. I wonder what other installers do...
I haven't looked at hijacking the tty driver, but I'm wary for the same
reasons. I'd suggest not trying to take over anybody else's
major/minor.
--
Hollis Blanchard
IBM Linux Technology Center
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home