On Mon, Oct 01, 2012 at 12:21:18PM +0200, Jan Kiszka wrote: > On 2012-10-01 11:31, Marcelo Tosatti wrote: > > On Mon, Oct 01, 2012 at 10:05:21AM +0200, Jan Kiszka wrote: > >> On 2012-09-30 21:11, Marcelo Tosatti wrote: > >>> > >>> Option is deprecated and warning has been in place for one year. > >> > >> Do we really care about such cosmetics? > > > > We care about removing qemu-kvm to null. > > > >> What is the big plan for > >> qemu-kvm now? For 1.3 and then beyond? > > > > I suggested this: provide a configuration file (and proper guide on > > how to use it on announce email) to be shipped with qemu 1.3.0. > > > > That is: > > > > "For compatibility with qemu-kvm 1.2.0, use > > > > qemu-system-x86_64 -config /usr/share/qemu/qemu-kvm-1.2-compat.opt" > > > > This would work for rtl8139-as-default, vga-ram-size differences. > > > > And drop all command line option compatibility (which can be easily fixed > > by an administrator/end user). > > > > Comments? > > It's not just about default configs. We need to validate if the > migration formats are truly compatible (qemu-kvm -> QEMU, the other way > around definitely not). Right, VGA RAM size differences are part of migration compatibility. The other two are ACPI and i8254 (will be looking into details soon, thanks). > For the command line switches, we could provide > a wrapper script that translates them into upstream format or simply > ignores them. That should be harmless to carry upstream. Do you have an objection against just pushing the responsability to administrators? It can be seen as configuration file format change. Most users should not be using direct command line anyway. > But I would really stop worrying about the qemu-kvm code base. > > Jan Right, thats what we're trying to do here. -- 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
