On 08/03/2010 09:26 PM, Anthony Liguori wrote:
On 08/03/2010 12:58 PM, Avi Kivity wrote:
On 08/03/2010 08:42 PM, Anthony Liguori wrote:
However, I don't think we can objectively differentiate between a
"major" and "minor" user. Generally speaking, I would rather that
we not take the position of "you are a minor user therefore we're
not going to accommodate you".
Again it's a matter of practicalities. With have written virtio
drivers for Windows and Linux, but not for FreeDOS or NetWare. To
speed up Windows XP we have (in qemu-kvm) kvm-tpr-opt.c that is a
gross breach of decency, would we go to the same lengths to speed up
Haiku? I suggest that we would not.
tpr-opt optimizes a legitimate dependence on the x86 architecture that
Windows has. While the implementation may be grossly indecent, it
certainly fits the overall mission of what we're trying to do in qemu
and kvm which is emulate an architecture.
You've invested a lot of time and effort into it because it's
important to you (or more specifically, your employer). That's
because Windows is important to you.
Correct.
If someone as adept and commit as you was heavily invested in Haiku
and was willing to implement something equivalent to tpr-opt and also
willing to do all of the work of maintaining it, then reject such a
patch would be a mistake.
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should
discourage people from depending on this interface for production use.
If Richard is willing to do the work to make -kernel perform faster in
such a way that it fits into the overall mission of what we're
building, then I see no reason to reject it. The criteria for
evaluating a patch should only depend on how it affects other areas of
qemu and whether it impacts overall usability.
That's true, but extending fwcfg doesn't fit into the overall picture
well. We have well defined interfaces for pushing data into a guest:
virtio-serial (dma upload), virtio-blk (adds demand paging), and
virtio-p9fs (no image needed). Adapting libguestfs to use one of these
is a better move than adding yet another interface.
A better (though still inaccurate) analogy is would be if the developers
of a guest OS came up with a virtual bus for devices and were willing to
do the work to make this bus perform better. Would we accept this new
work or would we point them at our existing bus (pci) instead?
Really, the bar on new interfaces (both to guest and host) should be
high, much higher than it is now. Interfaces should be well documented,
future proof, migration safe, and orthogonal to existing interfaces.
While the first three points could be improved with some effort, adding
a new dma interface is not going to be orthogonal to virtio. And
frankly, libguestfs is better off switching to one of the other
interfaces. Slurping huge initrds isn't the right way to do this.
As a side note, we ought to do a better job of removing features that
have created a burden on other areas of qemu that aren't actively
being maintained. That's a different discussion though.
Sure, we need something like Linux'
Documentation/feature-removal-schedule.txt for people to ignore.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
