qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 10/19] monitor: Convert do_info_name() to QObjec


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 10/19] monitor: Convert do_info_name() to QObject
Date: Thu, 10 Dec 2009 17:38:13 +0000
User-agent: Mutt/1.4.1i

On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:
> On Thu, 10 Dec 2009 18:24:38 +0200
> Avi Kivity <address@hidden> wrote:
> 
> > > Let me put it another way, I don't think adding null to the json 
> > > parser and incorporating it into this command is a good idea at this 
> > > stage in the release so if we want to do something like this, we need 
> > > to defer it to 0.13.
> > >
> > > I agree there are some instances where null could be useful.  I think 
> > > we can get away without it here though.
> > 
> > For 'name', definitely, since it's known to exist.  It would be nice to 
> > have consistency in how features are presented, though.
> 
>  Following what you propose, if it's known to exist then we should
> never return an empty dict.
> 
>  There are other commands that might require adjustments, for example
> 'info kvm' has a 'present' key. If QEMU is built w/o KVM support, then
> this key will be 'false'. Should we return an empty dict then?
> 
>  HPET is another example, currently it's only compiled in if the
> target is i386. Otherwise the command won't even be available, and
> we have more commands with conditional features/compilation.
> 
>  So, what I arguably did wrong here was starting the conversion
> work before defining all these rules.
> 
>  An option we have is: libvirt actually uses four or five of those
> info commands. So, we could drop all the rest and guarantee that
> only those libvirt ones are 100% correct.

Please don't do that. libvirt is adding support for new features all the
time. I don't want to be in the situation where we can't add a new feature
because it is missing in the JSON impl. If we're going to provide a supported
JSON monitor it needs to have all the commands converted, otherwise we'll
have to stick with using the text based monitor.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

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