| Message ID | 1260376078-8694-11-git-send-email-lcapitulino@redhat.com |
|---|---|
| State | New |
| Headers | show |
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",
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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 >
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.
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
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",
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> --- monitor.c | 29 +++++++++++++++++++++++++---- 1 files changed, 25 insertions(+), 4 deletions(-)