From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm: remove "boot=on|off" drive parameter compatibility Date: Mon, 01 Oct 2012 15:14:18 +0200 Message-ID: <5069972A.9010704@siemens.com> References: <20120930191146.GA20012@amt.cnet> <50694EC1.8060006@siemens.com> <20121001093102.GA14797@amt.cnet> <50696E9E.7030302@siemens.com> <20121001130345.GA2475@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm To: Marcelo Tosatti Return-path: Received: from goliath.siemens.de ([192.35.17.28]:22975 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753261Ab2JANO3 (ORCPT ); Mon, 1 Oct 2012 09:14:29 -0400 In-Reply-To: <20121001130345.GA2475@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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