Re: [Qemu-trivial] [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line

[Anthony Liguori]

Andreas Färber <address@hidden> writes:

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

Nope.

>> 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

Sounds like a good reason to submit the target upstream to me...

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

There's no need to keep it in sorted order.  We should just add stuff to
the end of the enum.

Heck, if someone wants to send a patch to randomize the sort order,
that'd be fine too :-)

Regards,

Anthony Liguori

> 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. ;)
>
> Regards,
> Andreas
>
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg