On Sun, Nov 15, 2009 at 04:41:26PM +0100, Jan Kiszka wrote: > Avi Kivity wrote: > > On 11/15/2009 05:02 PM, Jan Kiszka wrote: > >> > >> Where should I add "/* next version to use: 13 */", and who will take > >> care that this comment will also be kept up to date? The CPU vmstate is > >> already ordered according to logical groups, just look at earlier field. > >> Only recent KVM additions happened to create some version ordering as > >> well. > >> > > > > Er, now I'm confused. 11 and 12 indeed do already exist, so how can you > > update 11 retroactively? > > Oh, right, good that we discuss this. My patch dated back before the > kvmclock addition, which IMHO incorrectly bumped the version numbers. I > think the current policy in upstream is that we only increment once per > qemu release, not per bit added. > > > > > Shouldn't you create 13 now? > > No, I rather think Glauber's 12 should be downgraded to 11 - unless it > misses the qemu merge windows for 0.12. My extensions definitely target > that release, thus will likely carry 11 in upstream. And we should > really try to avoid diverging again. Agree. Anthony, Are Glauber patches going to make it for 0.12, so we can revert current qemu-kvm's CPU_SAVE_VERSION from 12 to 11? Thanks. > > > > > (and I meant: /* The above list is not sorted wrt version, watch out! > > */, but now I feel I'm missing something). > > > > Ok, can add such a note at the end. > > Jan > -- 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
