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


RE: [Xen-devel] Re: [Xen-changelog] If Xen is told to use a serial conso

To: "Hollis Blanchard" <hollisb@xxxxxxxxxx>, "Xen Development List" <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [Xen-changelog] If Xen is told to use a serial console via a com1= or com2= directive
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 24 Mar 2005 16:14:00 -0000
Cc: <ian.pratt@xxxxxxxxxxxx>
Delivery-date: Thu, 24 Mar 2005 16:17:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Thread-index: AcUwiXsdIk1vyc5lSF6Muc7o2X2HYwAAjyGA
Thread-topic: [Xen-devel] Re: [Xen-changelog] If Xen is told to use a serial console via a com1= or com2= directive
> 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.

If you have a COM port configured in Xen the default behaviour has been
for xencons to grab ttyS0. This has been the case for some time, and as
far as I'm aware this works smoothly with anaconda and other installers
-- at least I haven't heard of any complaints.

The problem I was alluding to in my checkin comments was when you have
both xencons and an 8250 driver. It's not possible for xencons to
register as ttyS0 in this instance, though registering as a high number
ttyS seems to work OK.

I considered registering a xencons specific major/minor e.g. ttyX0, but
that requires support in the distros, udev, devfs etc. Since the
intention is to loosely emulate a serial driver, I don't think what
we're doing is too evil. It seems to work and is good from a user
experience POV (excepting the 8250 and xencons case).


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_idh83&alloc_id149&op=click
Xen-devel mailing list

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