qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migrati


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
Date: Sun, 31 Jul 2011 19:15:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 07/31/2011 06:10 PM, Christoph Hellwig wrote:
On Sun, Jul 31, 2011 at 11:43:08PM +0300, Dor Laor wrote:
/me caught off guard. I wonder why it wasn't converted to VMSTATE before?
virtio is one of the key devices, it's not just random forgotten one that
might not care about migration.

It just shows the extent of incomplete transitions in qemu.  Given how
much burden incomplete transitions have on software projects we should
try to minimize them in qemu.  That is if people add a new API we need
to have a clear roadmap when it's going to be finished, and more importantly
what the consequence of not finishing it are instead of leaving it half
done.  I think the way the Linux kernel handles API transitions is something
qemu could borrow from. For most of them it's simply expected to do a simple
conversion of all users of an API to the new equivalent, maybe it in
simplistic and dumb way, but at least a transition.  Combined with a
deprectation schedule for unused drivers that seems to do wonders, although
of course even the Linux kernel is slacking in some areas.

One of the things I think the kernel is good at, is making relatively large changes outside of the tree and then merging it in a way that makes sense when it makes sense.

I think we've set the bar too low historically for introducing new interfaces. I think Avi's new memory API is a good example of how we should approach these things--do the vast majority of the thankless work up front before initial merge.

Besides making sure we don't have incomplete interfaces, it also helps validate the interface before committing to it.

Regards,

Anthony Liguori







reply via email to

[Prev in Thread] Current Thread [Next in Thread]