Hollis Blanchard
2005-Mar-24 15:49 UTC
[Xen-devel] Re: [Xen-changelog] If Xen is told to use a serial console via a com1= or com2= directive
On Mar 23, 2005, at 9:10 PM, BitKeeper Bot wrote:> ChangeSet 1.1358, 2005/03/24 03:10:42+00:00, > iap10@freefall.cl.cam.ac.uk > > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel