Patchwork [10/19] monitor: Convert do_info_name() to QObject

login
register
mail settings
Submitter Luiz Capitulino
Date Dec. 9, 2009, 4:27 p.m.
Message ID <1260376078-8694-11-git-send-email-lcapitulino@redhat.com>
Download mbox | patch
Permalink /patch/40745/
State New
Headers show

Comments

Luiz Capitulino - Dec. 9, 2009, 4:27 p.m.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 monitor.c |   29 +++++++++++++++++++++++++----
 1 files changed, 25 insertions(+), 4 deletions(-)
Markus Armbruster - Dec. 10, 2009, 10:09 a.m.
Luiz Capitulino <lcapitulino@redhat.com> writes:

> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> ---
>  monitor.c |   29 +++++++++++++++++++++++++----
>  1 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/monitor.c b/monitor.c
> index 47f794d..3d33bd8 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -514,10 +514,30 @@ static void do_info_version(Monitor *mon, QObject **ret_data)
>                                     QEMU_VERSION, QEMU_PKGVERSION);
>  }
>  
> -static void do_info_name(Monitor *mon)
> +static void do_info_name_print(Monitor *mon, const QObject *data)
>  {
> -    if (qemu_name)
> -        monitor_printf(mon, "%s\n", qemu_name);
> +    const char *str;
> +
> +    str = qdict_get_str(qobject_to_qdict(data), "name");
> +    if (strlen(str) > 0) {
> +        monitor_printf(mon, "%s\n", str);
> +    }
> +}
> +
> +/**
> + * do_info_name(): Show VM name
> + *
> + * Return a QDict with the following information:
> + *
> + * - "name": VM's name. If the VM has no name, the string will be empty

So you can't distinguish name "" from unnamed.  Do we care?

Monitor output for unnamed guests changes from

    (qemu) info name
    (qemu) 

to

(qemu) info name

(qemu) 

> + *
> + * Example:
> + *
> + * { "name": "qemu-name" }
> + */
> +static void do_info_name(Monitor *mon, QObject **ret_data)
> +{
> +    *ret_data = qobject_from_jsonf("{'name': %s}", qemu_name ? qemu_name : "");
>  }
>  
>  /**
> @@ -2449,7 +2469,8 @@ static const mon_cmd_t info_cmds[] = {
>          .args_type  = "",
>          .params     = "",
>          .help       = "show the current VM name",
> -        .mhandler.info = do_info_name,
> +        .user_print = do_info_name_print,
> +        .mhandler.info_new = do_info_name,
>      },
>      {
>          .name       = "uuid",
Luiz Capitulino - Dec. 10, 2009, 11:52 a.m.
On Thu, 10 Dec 2009 11:09:53 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> writes:
> 
> > Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> > ---
> >  monitor.c |   29 +++++++++++++++++++++++++----
> >  1 files changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/monitor.c b/monitor.c
> > index 47f794d..3d33bd8 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -514,10 +514,30 @@ static void do_info_version(Monitor *mon, QObject **ret_data)
> >                                     QEMU_VERSION, QEMU_PKGVERSION);
> >  }
> >  
> > -static void do_info_name(Monitor *mon)
> > +static void do_info_name_print(Monitor *mon, const QObject *data)
> >  {
> > -    if (qemu_name)
> > -        monitor_printf(mon, "%s\n", qemu_name);
> > +    const char *str;
> > +
> > +    str = qdict_get_str(qobject_to_qdict(data), "name");
> > +    if (strlen(str) > 0) {
> > +        monitor_printf(mon, "%s\n", str);
> > +    }
> > +}
> > +
> > +/**
> > + * do_info_name(): Show VM name
> > + *
> > + * Return a QDict with the following information:
> > + *
> > + * - "name": VM's name. If the VM has no name, the string will be empty
> 
> So you can't distinguish name "" from unnamed.  Do we care?

 I don't think so, but if we do the best way to deal with the fact
that qemu_name can be NULL would be to return null, like:

{ "name": null }

 But we don't support json-null yet... There are other two
ways to solve this, but they seem workarounds for not supporting
null: return an empty dict or return { "name": false }.

> Monitor output for unnamed guests changes from
> 
>     (qemu) info name
>     (qemu) 
> 
> to
> 
> (qemu) info name
> 
> (qemu) 

 The strlen() call doesn't let this happen. Although the
other way around does happen: if you call qemu with -name '',
then output would be:

(qemu) info name

(qemu)

 This won't happen anymore, goto do_we_care.
Anthony Liguori - Dec. 10, 2009, 12:56 p.m.
Luiz Capitulino wrote:
> On Thu, 10 Dec 2009 11:09:53 +0100
> Markus Armbruster <armbru@redhat.com> wrote:
>
>   
>> Luiz Capitulino <lcapitulino@redhat.com> writes:
>>
>>     
>>> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
>>> ---
>>>  monitor.c |   29 +++++++++++++++++++++++++----
>>>  1 files changed, 25 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/monitor.c b/monitor.c
>>> index 47f794d..3d33bd8 100644
>>> --- a/monitor.c
>>> +++ b/monitor.c
>>> @@ -514,10 +514,30 @@ static void do_info_version(Monitor *mon, QObject **ret_data)
>>>                                     QEMU_VERSION, QEMU_PKGVERSION);
>>>  }
>>>  
>>> -static void do_info_name(Monitor *mon)
>>> +static void do_info_name_print(Monitor *mon, const QObject *data)
>>>  {
>>> -    if (qemu_name)
>>> -        monitor_printf(mon, "%s\n", qemu_name);
>>> +    const char *str;
>>> +
>>> +    str = qdict_get_str(qobject_to_qdict(data), "name");
>>> +    if (strlen(str) > 0) {
>>> +        monitor_printf(mon, "%s\n", str);
>>> +    }
>>> +}
>>> +
>>> +/**
>>> + * do_info_name(): Show VM name
>>> + *
>>> + * Return a QDict with the following information:
>>> + *
>>> + * - "name": VM's name. If the VM has no name, the string will be empty
>>>       
>> So you can't distinguish name "" from unnamed.  Do we care?
>>     
>
>  I don't think so, but if we do the best way to deal with the fact
> that qemu_name can be NULL would be to return null, like:
>
> { "name": null }
>
>  But we don't support json-null yet... There are other two
> ways to solve this, but they seem workarounds for not supporting
> null: return an empty dict or return { "name": false }.
>   

I'd prefer an empty dict.  I actually prefer that over null.
Avi Kivity - Dec. 10, 2009, 3:55 p.m.
On 12/10/2009 02:56 PM, Anthony Liguori wrote:
>
> I'd prefer an empty dict.  I actually prefer that over null.
>

Depends.  Key not present suggests the feature is not implemented.  
Value is null suggests the feature is not used.  Both key and value 
present suggest the feature is in implemented and active.
Avi Kivity - Dec. 10, 2009, 3:57 p.m.
On 12/10/2009 05:55 PM, Avi Kivity wrote:
> On 12/10/2009 02:56 PM, Anthony Liguori wrote:
>>
>> I'd prefer an empty dict.  I actually prefer that over null.
>>
>
> Depends.  Key not present suggests the feature is not implemented.  
> Value is null suggests the feature is not used.  Both key and value 
> present suggest the feature is in implemented and active.
>

And, as with hex numbers, we need to prefer usability to machine clients 
to readability to user beings.  This is a machine protocol, so unless 
you're a machine, aesthetic considerations take second place.
Anthony Liguori - Dec. 10, 2009, 4:03 p.m.
Avi Kivity wrote:
> On 12/10/2009 02:56 PM, Anthony Liguori wrote:
>>
>> I'd prefer an empty dict.  I actually prefer that over null.
>>
>
> Depends.  Key not present suggests the feature is not implemented.  
> Value is null suggests the feature is not used.  Both key and value 
> present suggest the feature is in implemented and active.

What I suggested to Luiz was that all info commands return a 
dictionary.  The main reason was that for most commands, we can extend 
the commands in a compatible way by adding new fields to the dictionary.

My expectation is that there will be a lot of client code that does:

hpet_info = qmp.info_hpet()
if hpet_info.has_key('period'):
   period = hpet_info['period']
else:
   period = 100 # old qemu's has a fixed period of 100ns

So in keeping with this idiom, I think that checking 
name_info.has_key('name') is a more meaningful way to determine whether 
the virtual machine has been given a name vs comparing name_info['name'] 
== None.
Avi Kivity - Dec. 10, 2009, 4:10 p.m.
On 12/10/2009 06:03 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> On 12/10/2009 02:56 PM, Anthony Liguori wrote:
>>>
>>> I'd prefer an empty dict.  I actually prefer that over null.
>>>
>>
>> Depends.  Key not present suggests the feature is not implemented.  
>> Value is null suggests the feature is not used.  Both key and value 
>> present suggest the feature is in implemented and active.
>
> What I suggested to Luiz was that all info commands return a 
> dictionary.  The main reason was that for most commands, we can extend 
> the commands in a compatible way by adding new fields to the dictionary.

Oh yes.

>
> My expectation is that there will be a lot of client code that does:
>
> hpet_info = qmp.info_hpet()
> if hpet_info.has_key('period'):
>   period = hpet_info['period']
> else:
>   period = 100 # old qemu's has a fixed period of 100ns
>
> So in keeping with this idiom, I think that checking 
> name_info.has_key('name') is a more meaningful way to determine 
> whether the virtual machine has been given a name vs comparing 
> name_info['name'] == None.

But we have two null conditions to check for, in an extendible dictionary:

1. The feature is unknown to qemu
2. The feature is known to qemu, but disabled

So, "if 'field' in result:" tests the former, and "if result['field']:" 
tests the latter.

In your example, a period of None makes no sense, so it would be 
sufficient to

   period = hpet_info.get('period', 0.100)
Anthony Liguori - Dec. 10, 2009, 4:20 p.m.
Avi Kivity wrote:
> But we have two null conditions to check for, in an extendible 
> dictionary:
>
> 1. The feature is unknown to qemu
> 2. The feature is known to qemu, but disabled
>
> So, "if 'field' in result:" tests the former, and "if 
> result['field']:" tests the latter.
>
> In your example, a period of None makes no sense, so it would be 
> sufficient to
>
>   period = hpet_info.get('period', 0.100)

By the same token, wouldn't you probably do:

name = hpet_info.get('name', None)

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.
Avi Kivity - Dec. 10, 2009, 4:24 p.m.
On 12/10/2009 06:20 PM, Anthony Liguori wrote:
>
> By the same token, wouldn't you probably do:
>
> name = hpet_info.get('name', None)
>

For name, yes.  For an optional feature where you're interested in 
knowing both its existence and its value (if it exists), no.

> 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.
Luiz Capitulino - Dec. 10, 2009, 4:54 p.m.
On Thu, 10 Dec 2009 18:24:38 +0200
Avi Kivity <avi@redhat.com> 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.
Avi Kivity - Dec. 10, 2009, 5:02 p.m.
On 12/10/2009 06:54 PM, Luiz Capitulino wrote:
> On Thu, 10 Dec 2009 18:24:38 +0200
> Avi Kivity<avi@redhat.com>  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.
>    

Right, but if we can't support null (why?) then we can make an exception 
for 'name'.

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

No.

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

That's fine, as long as command availability is discoverable.

>   So, what I arguably did wrong here was starting the conversion
> work before defining all these rules.
>    

On the other hand, we can often only find out something by implementing 
it incorrectly first.

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

My worry is with the commands that parse or emit comma-separated option 
strings.
Luiz Capitulino - Dec. 10, 2009, 5:12 p.m.
On Thu, 10 Dec 2009 19:02:37 +0200
Avi Kivity <avi@redhat.com> wrote:

> On 12/10/2009 06:54 PM, Luiz Capitulino wrote:
> > On Thu, 10 Dec 2009 18:24:38 +0200
> > Avi Kivity<avi@redhat.com>  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.
> >    
> 
> Right, but if we can't support null (why?) then we can make an exception 
> for 'name'.

 I'm ok with the exception too and the problem with adding null support
now is that it requires some changes to the parser which seem a bit
late to be done.

> >   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?
> >    
> 
> No.
> 
> >   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.
> >
> >    
> 
> That's fine, as long as command availability is discoverable.

 Yes, it's.

> >   So, what I arguably did wrong here was starting the conversion
> > work before defining all these rules.
> >    
> 
> On the other hand, we can often only find out something by implementing 
> it incorrectly first.

 Sure and even being inconsistent a bit I'm quite sure that it's a lot
better than parsing the old user monitor. :)

> >   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.
> >    
> 
> My worry is with the commands that parse or emit comma-separated option 
> strings.

 I tried to fix all emissions, but we accept it like in the uri
argument of migrate.

 I don't think it's a big deal though, as it's easy to add a new
key for that (if needed) w/o breaking compatibility.
Daniel P. Berrange - Dec. 10, 2009, 5:38 p.m.
On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:
> On Thu, 10 Dec 2009 18:24:38 +0200
> Avi Kivity <avi@redhat.com> 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
Luiz Capitulino - Dec. 10, 2009, 5:49 p.m.
On Thu, 10 Dec 2009 17:38:13 +0000
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:

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

 I won't.

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

 But 0.12 won't have all commands converted, this page has a listing
of what we're going to have:

http://www.linux-kvm.org/page/MonitorProtocol#Conversion_work_detailed_status

 'converted' and 'merged' are guaranteed, Markus did some work and enabled
one or two which are not there.

 I know that the usb and net ones are vital for you, I've patches enabling
them but their error handling is very difficult to get right.
Daniel P. Berrange - Dec. 10, 2009, 6 p.m.
On Thu, Dec 10, 2009 at 03:49:20PM -0200, Luiz Capitulino wrote:
> On Thu, 10 Dec 2009 17:38:13 +0000
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
> 
> > On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:
> 
> > >  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.
> 
>  I won't.
> 
> > 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.
> 
>  But 0.12 won't have all commands converted, this page has a listing
> of what we're going to have:
> 
> http://www.linux-kvm.org/page/MonitorProtocol#Conversion_work_detailed_status
> 
>  'converted' and 'merged' are guaranteed, Markus did some work and enabled
> one or two which are not there.
> 
>  I know that the usb and net ones are vital for you, I've patches enabling
> them but their error handling is very difficult to get right.

The list of what libvirt uses is also outdated. In addition to those in
yellow, we also now use, or will likely use in near future

  device_add
  device_del
  info pci
  set_link
  migrate_cancel
  migrate_set_downtime
  drive_add
  info usb

So given the 0.12 release target, it sounds like we won't be able to
use the JSON monitor :-(

Regards,
Daniel
Luiz Capitulino - Dec. 11, 2009, 12:54 p.m.
On Thu, 10 Dec 2009 18:00:31 +0000
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Thu, Dec 10, 2009 at 03:49:20PM -0200, Luiz Capitulino wrote:
> > On Thu, 10 Dec 2009 17:38:13 +0000
> > "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > 
> > > On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:
> > 
> > > >  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.
> > 
> >  I won't.
> > 
> > > 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.
> > 
> >  But 0.12 won't have all commands converted, this page has a listing
> > of what we're going to have:
> > 
> > http://www.linux-kvm.org/page/MonitorProtocol#Conversion_work_detailed_status
> > 
> >  'converted' and 'merged' are guaranteed, Markus did some work and enabled
> > one or two which are not there.
> > 
> >  I know that the usb and net ones are vital for you, I've patches enabling
> > them but their error handling is very difficult to get right.
> 
> The list of what libvirt uses is also outdated. In addition to those in
> yellow, we also now use, or will likely use in near future
> 
>   device_add
>   device_del
>   info pci
>   set_link
>   migrate_cancel
>   migrate_set_downtime
>   drive_add
>   info usb
> 
> So given the 0.12 release target, it sounds like we won't be able to
> use the JSON monitor :-(

 Well, given that we have only a few days before the final release it'll
be very hard to properly convert those.

 But there's something we could do if libvirt early adoption is a hard
requirement.

 You need two info handlers and some command handlers. The latter is
trivial to 'enable for usage' if it doesn't have user output, which is
the case for most command handlers.

 The problem though is error handling. Enabling a handler for QMP usage
w/o adding proper error handling support means that you won't be able
to get most error conditions. In the best case you'll get a generic error
message, in the worst QEMU won't even detect the error.

 This is doable, but doesn't sound like a good idea. Specially if today
libvirt is able to handle error conditions with the user protocol.
Anthony Liguori - Dec. 11, 2009, 1:14 p.m.
Luiz Capitulino wrote:
>> The list of what libvirt uses is also outdated. In addition to those in
>> yellow, we also now use, or will likely use in near future
>>
>>   device_add
>>   device_del
>>   info pci
>>   set_link
>>   migrate_cancel
>>   migrate_set_downtime
>>   drive_add
>>   info usb
>>
>> So given the 0.12 release target, it sounds like we won't be able to
>> use the JSON monitor :-(
>>     
>
>  Well, given that we have only a few days before the final release it'll
> be very hard to properly convert those.
>
>  But there's something we could do if libvirt early adoption is a hard
> requirement.
>   

It's too late.  I don't want to see anything but bug fixes go in post -rc2.
Anthony Liguori - Dec. 11, 2009, 1:18 p.m.
Luiz Capitulino wrote:
> On Thu, 10 Dec 2009 18:24:38 +0200
> Avi Kivity <avi@redhat.com> 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.
>   

The monitor in general is very ad-hoc.  The fact that the info commands 
don't behave consistently shouldn't be a surprise.

Let's focus on converting the remaining monitor commands.  The goal is 
that any user of the monitor today can convert over to QMP.

Once we've achieved that goal, let's start looking at introducing proper 
commands that make sense and are consistent.
Anthony Liguori - Dec. 11, 2009, 1:20 p.m.
Daniel P. Berrange wrote:
> 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.
>   

I would suggest that for 0.12, libvirt not use QMP.  It should wait 
until 0.13 to convert over to QMP since we should have a full conversion 
by then.

> Daniel
>
Luiz Capitulino - Dec. 11, 2009, 1:27 p.m.
On Fri, 11 Dec 2009 07:18:27 -0600
Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:

> Let's focus on converting the remaining monitor commands.  The goal is 
> that any user of the monitor today can convert over to QMP.
> 
> Once we've achieved that goal, let's start looking at introducing proper 
> commands that make sense and are consistent.

 ACK.
Daniel P. Berrange - Dec. 11, 2009, 7:46 p.m.
On Fri, Dec 11, 2009 at 07:20:12AM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >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.
> >  
> 
> I would suggest that for 0.12, libvirt not use QMP.  It should wait 
> until 0.13 to convert over to QMP since we should have a full conversion 
> by then.

I agree, given the time lines involved its not practical for us to
switch to QMP in 0.12, so we'll wait until 0.13. On the plus side
we've got all the QMP code in libvirt GIT now, so we can make sure
that 0.13 is very well tested when time comes for its release :-)

Daniel

Patch

diff --git a/monitor.c b/monitor.c
index 47f794d..3d33bd8 100644
--- a/monitor.c
+++ b/monitor.c
@@ -514,10 +514,30 @@  static void do_info_version(Monitor *mon, QObject **ret_data)
                                    QEMU_VERSION, QEMU_PKGVERSION);
 }
 
-static void do_info_name(Monitor *mon)
+static void do_info_name_print(Monitor *mon, const QObject *data)
 {
-    if (qemu_name)
-        monitor_printf(mon, "%s\n", qemu_name);
+    const char *str;
+
+    str = qdict_get_str(qobject_to_qdict(data), "name");
+    if (strlen(str) > 0) {
+        monitor_printf(mon, "%s\n", str);
+    }
+}
+
+/**
+ * do_info_name(): Show VM name
+ *
+ * Return a QDict with the following information:
+ *
+ * - "name": VM's name. If the VM has no name, the string will be empty
+ *
+ * Example:
+ *
+ * { "name": "qemu-name" }
+ */
+static void do_info_name(Monitor *mon, QObject **ret_data)
+{
+    *ret_data = qobject_from_jsonf("{'name': %s}", qemu_name ? qemu_name : "");
 }
 
 /**
@@ -2449,7 +2469,8 @@  static const mon_cmd_t info_cmds[] = {
         .args_type  = "",
         .params     = "",
         .help       = "show the current VM name",
-        .mhandler.info = do_info_name,
+        .user_print = do_info_name_print,
+        .mhandler.info_new = do_info_name,
     },
     {
         .name       = "uuid",