Re: [Qemu-devel] [RFC PATCH 0/4] build: TARGET_ARCH/ARCH2/TYPE simplification

[Eric Blake]

On 05/20/2013 11:23 AM, Paolo Bonzini wrote:
> We have three variables currently in config-target.h:
> 
> - TARGET_ARCH is used to create a unique per-arch symbol, used in #ifdefs.
>   It is also used as a string through config-target.h, but this is almost
>   always wrong.
> 
> - TARGET_ARCH2 is the name of the executable (minus the qemu-/qemu-system-
>   prefix); it is not available in config-target.h.
> 
> - TARGET_TYPE is an enum but is otherwise the same as TARGET_ARCH2
> 
> This series changes all uses of TARGET_ARCH to refer to TARGET_ARCH2
> instead (which is renamed to TARGET_NAME).  The TARGET_ARCH #define
> is dropped, only the per-arch symbol remains.  TARGET_TYPE is then also
> removed since it is serialized to the same string if TARGET_NAME is
> used directly.

[Ugg - there's no good way to convince Thunderbird to reply to just 4/4,
when you inline everything after your "-- " signoff...]

> +++ b/qapi-schema.json
> @@ -3008,22 +3008,6 @@
>  { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
>  
>  ##
> -# @TargetType
> -#
> -# Target CPU emulation type
> -#
> -# These parameters correspond to the softmmu binary CPU name that is 
> currently
> -# running.
> -#
> -# Since: 1.2.0
> -##
> -{ 'enum': 'TargetType',
> -  'data': [ 'alpha', 'arm', 'cris', 'i386', 'lm32', 'm68k', 'microblazeel',
> -            'microblaze', 'mips64el', 'mips64', 'mipsel', 'mips', 'moxie',
> -            'or32', 'ppc64', 'ppcemb', 'ppc', 's390x', 'sh4eb', 'sh4',
> -            'sparc64', 'sparc', 'unicore32', 'x86_64', 'xtensaeb', 'xtensa' 
> ] }
> -
> -##
>  # @TargetInfo:
>  #
>  # Information describing the QEMU target.
> @@ -3033,7 +3017,7 @@
>  # Since: 1.2.0
>  ##
>  { 'type': 'TargetInfo',
> -  'data': { 'arch': 'TargetType' } }
> +  'data': { 'arch': 'str' } }

No change to the wire format, and being type-safe didn't really add
anything (since a binary only supported a single arch, not the entire
enum of arches).  Chaning now will avoid us being locked into something
once introspection is added (deleting it after we have introspection may
still be possible, but it would be harder to prove that it is not
backwards incompatible at that point).  I'm okay with this deletion.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature