On 2011-12-12 18:37, Avi Kivity wrote: > On 12/12/2011 06:51 PM, Jan Kiszka wrote: >>> >>> Any thoughts on the qemu-kvm merge plan? Sounds painful. >> >> Pain will be where the existing qemu-kvm extensions collide with these >> refactored upstream devices (backend/frontend split specifically). >> That's where we have to merge very carefully. Haven't tried this yet, >> will give it a spin tomorrow or so. >> >> From that point on, disabling the new stuff for now and at some point >> switching over from the old one should be simple again. >> >> BTW, PIT+HPET+speaker will cause similar issues for the same reasons. >> > > 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. Moreover, there was and still is quite some upstream cleanup necessary, and that never goes well with the delta of qemu-kvm. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
