On 2012-10-01 15:03, Marcelo Tosatti wrote: > 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. This is about helping him in the most appropriate way. > > Most users should not be using direct command line anyway. If you are using the command line, you shouldn't care about qemu-kvm's legacy. But there might be home-grown management stacks or scripts around that have to be adjusted. So some wrapper may help in this process, either as reference or as intermediate adapter. > >> But I would really stop worrying about the qemu-kvm code base. >> >> Jan > > Right, thats what we're trying to do here. Just that I'm missing how this patch correlates with the goal to get QEMU ready for qemu-kvm users. :) Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE 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
