From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uf9R5-0002XS-HF for qemu-devel@nongnu.org; Wed, 22 May 2013 09:50:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uf9R0-0002QR-Jz for qemu-devel@nongnu.org; Wed, 22 May 2013 09:50:35 -0400 Message-ID: <519CCD21.8090008@suse.de> Date: Wed, 22 May 2013 15:50:25 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1369066884-431-1-git-send-email-peter.maydell@linaro.org> <519A50EE.8040804@redhat.com> <871u8zp34w.fsf@codemonkey.ws> In-Reply-To: <871u8zp34w.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , John Rigby , patches@linaro.org, qemu-trivial@nongnu.org, qemu-devel@nongnu.org, Paolo Bonzini Am 22.05.2013 15:15, schrieb Anthony Liguori: > Paolo Bonzini writes: >=20 >> Il 20/05/2013 18:21, Peter Maydell ha scritto: >>> Reformat the qapi-schema TargetType enumeration so that it has just >>> one target architecture name per line. This allows patches for >>> adding new targets to just add a single line, rather than having >>> to reformat most of the list (resulting in a hard-to-check diff). >>> >>> Signed-off-by: Peter Maydell >>> --- >>> d15a9c23 is an example of what you get otherwise. >>> >>> I would much prefer it if we autogenerated this list so you didn't >>> need to change this file at all to add a new target, but Anthony >>> is against that; so this is at least an improvement. >> >> I have queued a patch for 1.6 that would change this field to a free >> string. There is no use of this enum, not even for introspection. >=20 > I don't object to this, however.. >=20 >> You >> don't need to know what targets were supported in the version that you >> compiled from. Only one target is supported in this executable >> anyway. >=20 > It seems useful to me. One day we may support multiple targets per > executable. >=20 > There's no obvious place where all of the possible targets are listed s= o > from the point of view of someone trying to figure out what the > platforms are while writing a management tool, it seems like a useful > thing to have. Does today's API allow for returning multiple enum values? I doubt so... > We don't add targets very often... are we optimizing for an uncommon > scenario here? Well, lately every second release or so. More common is however that people start writing a new target and don't submit it yet (ahem!) while another target gets added, and the current form of rebreaking this block of enum values causes more conflicts than with Peter's proposal where the place to add new values is more likely to differ between targets and becomes more secure to add to. So if we don't go for Paolo's string version, Reviewed-by: Andreas F=E4rber One thought that crossed my mind was whether to put [ and ] on lines of their own to aid adding before alpha and after xtensa, but apart from aarch64 I couldn't think of such fringe target names. ;) Regards, Andreas --=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