"Michael S. Tsirkin" <m...@redhat.com> wrote: > On Wed, Nov 25, 2009 at 10:30:47AM +0100, Juan Quintela wrote: >> "Michael S. Tsirkin" <m...@redhat.com> wrote: >> > On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote: >> >> > A device already supports load for a range >> > of versions between X and Y. We want to support >> > saving to a range of versions. >> > >> > Which versions to use is a separate decision >> > which should be taken on run time, not >> > at startup time. >> >> Not in the general case. > > If that means "not in all cases", I agree. > But it seems pretty common for bugfixes. > >> Think that v8 brings featureX to one device. If you _know_ that you don't >> want to use feature X, startup time is the proper place. Important >> thing is not the savevm format (we can do any change here), what we >> really need is that the guest still runs on the destination, and for >> that you can't change the hardware too much. >> >> Later, Juan. > > I think it's clear: if you change guest visible properties > these are features that might belong in machine description. > If not - they don't belong in machine description.
Ah, ok. Now we have some agreement (this second part). About the 1st part, the difference is that I don't want yet another mechanism for this bugfixes, just use the same one that the machine description. I think we can state it as: - have different ways from bug fixes that guest visible changes pro: bugfixes get easier, con: we have _two_ mechanism - have a single way for bugfixes and guest visible changes pro: we only have one mechanism con: bugfixes are "elevated to the machine description" We can stop discussing here, because clearly none is better than the other. We have to just make a choice of one with its advantages and disadvantages. Later, Juan.
