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
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.
It opens xvc0, compares the terminal attributes to /dev/console. That isn't really reliable to do unilaterally on a serial port.
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.