From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJnfP-0008GS-JI for qemu-devel@nongnu.org; Thu, 04 Oct 2012 11:50:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJnTi-00063x-0V for qemu-devel@nongnu.org; Thu, 04 Oct 2012 11:36:54 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42363 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJnTh-00063G-NB for qemu-devel@nongnu.org; Thu, 04 Oct 2012 11:36:45 -0400 Message-ID: <506DAD06.1030803@suse.de> Date: Thu, 04 Oct 2012 17:36:38 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20121003105255.972669952@amt.cnet> <20121003105509.391284251@amt.cnet> <87fw5vhb5a.fsf@codemonkey.ws> <20121003150341.GA15164@amt.cnet> <506C5DED.7000705@web.de> <878vbn4gs9.fsf@codemonkey.ws> <506C74E0.8080409@web.de> <20121003182652.GA32381@amt.cnet> <506D56B1.8090804@web.de> <87626qiahv.fsf@codemonkey.ws> <506D9D82.2090202@siemens.com> In-Reply-To: <506D9D82.2090202@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [patch 2/6] Use machine options to emulate -no-kvm-irqchip List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann Am 04.10.2012 16:30, schrieb Jan Kiszka: > On 2012-10-04 16:21, Anthony Liguori wrote: >> -no-kvm should be included too. >=20 > Reminds me that we still need to agree on the final default accel strat= egy. >=20 >> >> I just ran across a user that was injecting '-no-kvm-irqchip' in their >> libvirt XML via a custom attribute. It turned out it was to work arou= nd >> broken MSI support in their funky guest they were running. It was the >> wrong solution to the problem but they were doing it regardless. >> >> The point is, there are users in the wild using these options. There'= s >> no reason to remove them if they are trivial to maintain (and they are >> in their current form). >=20 > So let's define a consistent policy for them all: > - warn on the command line on use > - avoid adding them to the help or other user documentation That's dangerous - at some point someone will notice and propose a patch documenting them and the reviewers may have forgotten by then why it was not documented in the first place. Better clearly document them in help output as "DEPRECATED, to be removed in future versions" or so. Andreas > - keep them until we rework the whole command line >=20 > Jan >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg