[Xen-devel] Re: [Xen-changelog] If Xen is told to use a serial console via a com1= or com2= directive

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

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