On 12/12/2011 07:42 PM, Jan Kiszka wrote: > > It's a little late for this, but refactoring qemu-kvm in-tree and then > > splitting it into patches would have been easier. Let's try it this way > > for the next batch. > > I thought about this, but it definitely takes a clean, qemu-kvm free > base as start. The point is to design something free of all the legacy, > only looking at the other code base to extract the logic. If qemu-kvm was merged into qemu as is, then I'm sure you'd be able to refactor it into good shape (though there might be a little less motivation). > Moreover, there was and still is quite some upstream cleanup necessary, > and that never goes well with the delta of qemu-kvm. That's a good point. -- 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