Bug 213938 - Xen dom0 serial device returns -EINVAL on TIOCGSERIAL
Xen dom0 serial device returns -EINVAL on TIOCGSERIAL
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel-xen (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Markus Armbruster
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-03 15:59 EST by Bill Nottingham
Modified: 2014-03-16 23:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-28 05:38:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2006-11-03 15:59:33 EST
Description of problem:

Realistically, if it's taking the place of a serial port, it would be
nice if it behaved a little more like one.

Would prevent configuring it as a serial console automatically, among
other things.

Version-Release number of selected component (if applicable):

kernel-xen-2.6.18-1.2798.fc6
Comment 1 Stephen Tweedie 2006-11-03 17:36:00 EST
There are different approaches we could take here.  The underlying problem is
that  there's only one console driver, but it's being attached in different
places depending on dom0 vs. domU, kernel options etc.

On dom0, with HV set up as com1=38400,8n1, I can give the kernel "xencons=xvc
console=xvc0" and kudzu *does* set up a console correctly.

In that case, how is kudzu detecting xvc0?  Making the kernel's ttyS0 "behave a
little more like" xvc0 would make a lot more sense than making it more like a
real serial driver, because it *is* a xen virtual console, routed through the HV.
Comment 2 Bill Nottingham 2006-11-06 11:56:27 EST
It opens xvc0, compares the terminal attributes to /dev/console. That isn't
really reliable to do unilaterally on a serial port.
Comment 4 Markus Armbruster 2007-03-28 05:38:51 EDT
xencons hijacks /dev/ttyS0 in dom0 if parameter xencons is not set, and in both
dom0 and domU if xencons=ttyS0.

Hijacking /dev/ttyS0 saves the user from having to set up getty on the proper
xen console device /dev/xvc0.  But it breaks programs that (reasonably!) assume
that /dev/ttyS0 is a serial device, which the xen console isn't.

One could attempt to turn the xen console into a more credible impostor of a
serial device, but that would have to happen upstream.  I doubt its worthwhile.
 That's why I close with resolution WONTFIX rather than UPSTREAM.

Instead, we should remove hijacking: make sure that xencons=xvc just works, and
make it the default.

If you disagree, please reopen the bug.

Note You need to log in before you can comment on or make changes to this bug.