Re: [PATCH v10 1/1] virtio_console: Add support for multiple portsfor generic guest and host communication
From: Anthony Liguori
Date: Fri Nov 06 2009 - 08:00:57 EST
Christian Borntraeger wrote:
I know that Anthony disagrees, but _If we start over_, I still think we should
use that chance and leave the old virtio console untouched and add a new driver
for the host guest communication. IMHO it turned out that there is only a tiny
bit of commonality. (most code pathes check for use_multiport and then do two
completely different things).
I like simplicity. According to David A. Wheeler's SLOCCount, the old console
has 141 lines of code and the I truly believe that a separate guest-host comm
vehicle would also be a lot simpler if it must not take care of the old
It's the wrong metrics for evaluating a device ABI. We should consider
device ABIs based on whether they make sense--not about how many lines
of code it takes to implement the Linux driver.
Fundamentally speaking, right now, virtio-console is a single stream
that acts as an interactive terminal. What we're looking to add here is
to support multiple terminals that can be enumerated in a rationale way.
I see no reason why that should be two separate devices.
On the other hand we all should agree on one driver vs. two drivers before we go
on. Everything else would be unfair to Amit, who had the unpleasant task to
implement conflicting review comments....
I agree and there are multiple maintainers on the qemu side who feel the
same way I do. I'm really strongly opposed to making this separate devices.
If you think it's easier, you can do a check in the virtio_probe
function that checks for the feature bits and calls a completely
separate virtio initialization routine so it ends up being two separate
files in Linux. But that's a Linux implementation detail.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/