From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJnv2-0006Zf-JT for qemu-devel@nongnu.org; Thu, 04 Oct 2012 12:05:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJnue-0007iO-C2 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 12:05:00 -0400 Received: from goliath.siemens.de ([192.35.17.28]:16867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJnue-0007hp-29 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 12:04:36 -0400 Message-ID: <506DB38F.4010704@siemens.com> Date: Thu, 04 Oct 2012 18:04:31 +0200 From: Jan Kiszka 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> <506DAD06.1030803@suse.de> In-Reply-To: <506DAD06.1030803@suse.de> 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Anthony Liguori , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Gerd Hoffmann On 2012-10-04 17:36, Andreas F=E4rber wrote: > Am 04.10.2012 16:30, schrieb Jan Kiszka: >> On 2012-10-04 16:21, Anthony Liguori wrote: >>> -no-kvm should be included too. >> >> Reminds me that we still need to agree on the final default accel stra= tegy. >> >>> >>> I just ran across a user that was injecting '-no-kvm-irqchip' in thei= r >>> libvirt XML via a custom attribute. It turned out it was to work aro= und >>> broken MSI support in their funky guest they were running. It was th= e >>> 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 ar= e >>> in their current form). >> >> So let's define a consistent policy for them all: >> - warn on the command line on use >=20 >> - avoid adding them to the help or other user documentation >=20 > That's dangerous - at some point someone will notice and propose a patc= h > documenting them and the reviewers may have forgotten by then why it wa= s > not documented in the first place. Better clearly document them in help > output as "DEPRECATED, to be removed in future versions" or so. -M is marked as deprecated in the file that you would have to mess up. Jan --=20 Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux