WARNING - OLD ARCHIVES

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

xen-devel

[Xen-devel] Re: [Xen-changelog] If Xen is told to use a serial console v

To: Xen Development List <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Xen-changelog] If Xen is told to use a serial console via a com1= or com2= directive
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Thu, 24 Mar 2005 09:49:23 -0600
Delivery-date: Thu, 24 Mar 2005 15:51:51 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E1DEJYG-0007gO-JW@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1DEJYG-0007gO-JW@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>