On 08/03/2010 07:53 PM, Anthony Liguori wrote:
On 08/03/2010 11:50 AM, Avi Kivity wrote:
On 08/03/2010 07:46 PM, Anthony Liguori wrote:
It doesn't appear to support live migration, or hiding the feature
for -M older.
It's not a good path to follow. Tomorrow we'll need to load 300MB
initrds and we'll have to rework this yet again. Meanwhile the
kernel and virtio support demand loading of any image size you'd
want to use.
firmware is totally broken with respect to -M older FWIW.
Well, then this is adding to the brokenness.
fwcfg dma is going to have exactly one user, libguestfs. Much better
to have libguestfs move to some other interface and improve are
users-to-interfaces ratio.
You mean, only one class of users cares about the performance of
loading an initrd. However, you've also argued in other threads how
important it is not to break libvirt even if it means we have to do
silly things (like change help text).
So... why is it that libguestfs has to change itself and yet we should
bend over backwards so libvirt doesn't have to change itself?
libvirt is a major user that is widely deployed, and would be completely
broken if we change -help. Changing -help is of no consequence to us.
libguestfs is a (pardon me) minor user that is not widely used, and
would suffer a performance regression, not total breakage, unless we add
a fw-dma interface. Adding the interface is of consequence to us: we
have to implement live migration and backwards compatibility, and
support this new interface for a long while.
In an ideal world we wouldn't tolerate any regression. The world is not
ideal, so we prioritize.
the -help change scores very high on benfit/cost. fw-dma, much lower.
Note in both cases the long term solution is for the user to move to
another interface (cap reporting, virtio), so adding an interface which
would only be abandoned later by its only user drops the benfit/cost
ratio even further.
--
error compiling committee.c: too many arguments to function
--
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
