Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size

[Luiz Capitulino]

On Tue, 21 Aug 2012 11:07:50 +0100
"Daniel P. Berrange" <address@hidden> wrote:

> On Mon, Aug 20, 2012 at 04:02:39PM -0300, Luiz Capitulino wrote:
> > On Mon, 20 Aug 2012 15:31:38 +0100
> > "Daniel P. Berrange" <address@hidden> wrote:
> > 
> > > From: "Daniel P. Berrange" <address@hidden>
> > > 
> > > Add a 'query-target' QAPI command to allow management applications
> > > to determine what target architecture a QEMU binary is emulating
> > > without having to parse the binary name or -help output
> > > 
> > >   $ qmp-shell -p /tmp/qemu
> > >   (QEMU) query-target
> > >   {   u'return': {   u'arch': u'x86_64', u'bits': 64}}
> > > 
> > > Signed-off-by: Daniel P. Berrange <address@hidden>
> > > ---
> > >  arch_init.c      | 11 +++++++++++
> > >  qapi-schema.json | 25 +++++++++++++++++++++++++
> > >  qmp-commands.hx  |  5 +++++
> > >  3 files changed, 41 insertions(+)
> > > 
> > > diff --git a/arch_init.c b/arch_init.c
> > > index 9b46bfc..095672d 100644
> > > --- a/arch_init.c
> > > +++ b/arch_init.c
> > > @@ -1080,3 +1080,14 @@ int xen_available(void)
> > >      return 0;
> > >  #endif
> > >  }
> > > +
> > > +
> > > +TargetInfo *qmp_query_target(Error **errp)
> > > +{
> > > +    TargetInfo *info = g_malloc0(sizeof(*info));
> > > +
> > > +    info->arch = g_strdup(TARGET_ARCH);
> > > +    info->bits = TARGET_PHYS_ADDR_BITS;
> > > +
> > > +    return info;
> > > +}
> > > diff --git a/qapi-schema.json b/qapi-schema.json
> > > index 3d2b2d1..f0e3fe0 100644
> > > --- a/qapi-schema.json
> > > +++ b/qapi-schema.json
> > > @@ -2454,3 +2454,28 @@
> > >  #
> > >  ##
> > >  { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
> > > +
> > > +##
> > > +# @TargetInfo:
> > > +#
> > > +# Information describing the QEMU target.
> > > +#
> > > +# @arch: the name of the target architecture (eg "x86_64", "i686", etc)
> > 
> > Should be an enum, otherwise looks good.
> 
> Really ? It feels a little bit odd to make this an enum IMHO.

I don't think it's odd. We should avoid using free-form strings when
the set of possible values a command returns is limited and known.

The only small issue I see though, is that TARGET_ARCH is defined in
configure, so you'll have to add something like CONFIG_TARGET_ENUM there too
(although we could probably kill TARGET_ARCH and use the strings generated
by the qapi, but this might end resulting too much work for the hard-freeze).