[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to o

From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line
Date: Wed, 22 May 2013 15:50:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

Am 22.05.2013 15:15, schrieb Anthony Liguori:
> Paolo Bonzini <address@hidden> writes:
>> 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 <address@hidden>
>>> ---
>>> 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.
> I don't object to this, however..
>> 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.
> It seems useful to me.  One day we may support multiple targets per
> executable.
> There's no obvious place where all of the possible targets are listed so
> 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ärber <address@hidden>

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. ;)


SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]