[libvirt] [PATCH] show compiled in options in virsh --version
To ease debugging this trivial patch allows to find what was compiled in in the local version of libvirt, this doesn't work for remote access but that's probably sufficient. With the patch I get on my machine: paphio:~/libvirt/tools -> ./virsh --version Virsh command line tool of libvirt 0.8.4 See web site at http://libvirt.org/ Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline paphio:~/libvirt/tools -> instead of just "0.8.4" Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thu, Oct 28, 2010 at 03:00:45PM +0200, Daniel Veillard wrote:
To ease debugging this trivial patch allows to find what was compiled in in the local version of libvirt, this doesn't work for remote access but that's probably sufficient. With the patch I get on my machine:
paphio:~/libvirt/tools -> ./virsh --version Virsh command line tool of libvirt 0.8.4 See web site at http://libvirt.org/
Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline paphio:~/libvirt/tools ->
instead of just "0.8.4"
Hmm, if any script is running the current 'virsh --version' command to get the version number then this will break their usage. I think we should require a different and/or extra flag to print the extended data. --version is not a great place since this isn't really version information. Apache uses -v for plain version number, and -V for version number plus build options/info Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 10/28/2010 07:13 AM, Daniel P. Berrange wrote:
On Thu, Oct 28, 2010 at 03:00:45PM +0200, Daniel Veillard wrote:
To ease debugging this trivial patch allows to find what was compiled in in the local version of libvirt, this doesn't work for remote access but that's probably sufficient. With the patch I get on my machine:
paphio:~/libvirt/tools -> ./virsh --version Virsh command line tool of libvirt 0.8.4 See web site at http://libvirt.org/
Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline paphio:~/libvirt/tools ->
instead of just "0.8.4"
Hmm, if any script is running the current 'virsh --version' command to get the version number then this will break their usage. I think we should require a different and/or extra flag to print the extended data. --version is not a great place since this isn't really version information.
We already have: $ virsh version Compiled against library: libvir 0.8.2 Using library: libvir 0.8.2 Using API: QEMU 0.8.2 Running hypervisor: QEMU 0.12.5 Can we just beef that up, and leave 'virsh --version' as the short information?
Apache uses -v for plain version number, and -V for version number plus build options/info
Those are fine for short options; and for long options, ./configure already has the precedence of taking an optional argument. So maybe we could do: --version[=style], where style is short or long, defaults to short -v => --version=short -V => --version=long => 'virsh version' -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Thu, Oct 28, 2010 at 09:02:31AM -0600, Eric Blake wrote:
On 10/28/2010 07:13 AM, Daniel P. Berrange wrote:
On Thu, Oct 28, 2010 at 03:00:45PM +0200, Daniel Veillard wrote:
To ease debugging this trivial patch allows to find what was compiled in in the local version of libvirt, this doesn't work for remote access but that's probably sufficient. With the patch I get on my machine:
paphio:~/libvirt/tools -> ./virsh --version Virsh command line tool of libvirt 0.8.4 See web site at http://libvirt.org/
Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline paphio:~/libvirt/tools ->
instead of just "0.8.4"
Hmm, if any script is running the current 'virsh --version' command to get the version number then this will break their usage. I think we should require a different and/or extra flag to print the extended data. --version is not a great place since this isn't really version information.
We already have:
$ virsh version Compiled against library: libvir 0.8.2 Using library: libvir 0.8.2 Using API: QEMU 0.8.2 Running hypervisor: QEMU 0.12.5
Can we just beef that up, and leave 'virsh --version' as the short information?
Same name but different information. --version is telling you about the virsh binary version, while 'version' is telling you about the open connection to libvirt. Putting the virsh binary build options in 'version' would be somewhat misleading, because they don't reflect the open connection Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Oct 28, 2010 at 04:14:46PM +0100, Daniel P. Berrange wrote:
On Thu, Oct 28, 2010 at 09:02:31AM -0600, Eric Blake wrote:
We already have:
$ virsh version Compiled against library: libvir 0.8.2 Using library: libvir 0.8.2 Using API: QEMU 0.8.2 Running hypervisor: QEMU 0.12.5
Can we just beef that up, and leave 'virsh --version' as the short information?
Same name but different information. --version is telling you about the virsh binary version, while 'version' is telling you about the open connection to libvirt. Putting the virsh binary build options in 'version' would be somewhat misleading, because they don't reflect the open connection
Yeah I didn't want this to rely on a connection, it's not driver specific in any way, which is why --version was looking fine, but I will hook this to -V, that's very simple, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 29/10/2010, at 12:06 AM, Daniel Veillard <veillard@redhat.com> wrote:
Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline
Nice. Working remotely too would be awesome, but this looks like a good start. :)
On 10/28/2010 07:00 AM, Daniel Veillard wrote:
To ease debugging this trivial patch allows to find what was compiled in in the local version of libvirt, this doesn't work for remote access but that's probably sufficient. With the patch I get on my machine:
paphio:~/libvirt/tools -> ./virsh --version Virsh command line tool of libvirt 0.8.4 See web site at http://libvirt.org/
Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline paphio:~/libvirt/tools ->
instead of just "0.8.4"
+ vshPrint(ctl, _(" Hypervisors: ")); +#ifdef WITH_XEN + vshPrint(ctl, "Xen "); +#endif ... + vshPrint(ctl, "\n");
Rather than printing a trailing space, why not: vshPrint(ctl, _(" Hypervisors:")); #ifdef WITH_XEN vshPrint(ctl, " Xen"); #endif ... vshPrint(ctl, "\n");
+ + vshPrint(ctl, _(" Networking: ")); +#ifdef WITH_REMOTE + vshPrint(ctl, "Remote "); +#endif
Likewise for each category.
@@ -11521,8 +11644,7 @@ vshParseArgv(vshControl *ctl, int argc, char **argv) ctl->name = vshStrdup(ctl, optarg); break; case 'v': - /* FIXME - list a copyright blurb, as in GNU programs? */ - puts(VERSION); + vshShowVersion(ctl); exit(EXIT_SUCCESS);
Pre-existing bug - we don't detect write failure to stdout to exit with non-zero status. Unchanged by your patch. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Thu, Oct 28, 2010 at 11:21:16AM -0600, Eric Blake wrote:
On 10/28/2010 07:00 AM, Daniel Veillard wrote: [...]
+ vshPrint(ctl, _(" Hypervisors: ")); +#ifdef WITH_XEN + vshPrint(ctl, "Xen "); +#endif ... + vshPrint(ctl, "\n");
Rather than printing a trailing space, why not:
vshPrint(ctl, _(" Hypervisors:")); #ifdef WITH_XEN vshPrint(ctl, " Xen"); #endif ... vshPrint(ctl, "\n");
yeah, at some point I ended up with an extra space at the end of lines and though 'hum that could be improved', sure that's the best way :-)
@@ -11521,8 +11644,7 @@ vshParseArgv(vshControl *ctl, int argc, char **argv) ctl->name = vshStrdup(ctl, optarg); break; case 'v': - /* FIXME - list a copyright blurb, as in GNU programs? */ - puts(VERSION); + vshShowVersion(ctl); exit(EXIT_SUCCESS);
Pre-existing bug - we don't detect write failure to stdout to exit with non-zero status. Unchanged by your patch.
Not sure it's really a problem, but okay I will look. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
[adding bug-gnulib] On 10/28/2010 01:25 PM, Daniel Veillard wrote:
case 'v': - /* FIXME - list a copyright blurb, as in GNU programs? */ - puts(VERSION); + vshShowVersion(ctl); exit(EXIT_SUCCESS);
Pre-existing bug - we don't detect write failure to stdout to exit with non-zero status. Unchanged by your patch.
Not sure it's really a problem, but okay I will look.
The gnulib module closeout can automatically take care of this, but it is currently licensed as GPL. Jim, Bruno, are you okay with relicensing closeout and close-stream as LGPLv2+? -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
[adding bug-gnulib]
On 10/28/2010 01:25 PM, Daniel Veillard wrote:
case 'v': - /* FIXME - list a copyright blurb, as in GNU programs? */ - puts(VERSION); + vshShowVersion(ctl); exit(EXIT_SUCCESS);
Pre-existing bug - we don't detect write failure to stdout to exit with non-zero status. Unchanged by your patch.
Not sure it's really a problem, but okay I will look.
The gnulib module closeout can automatically take care of this, but it is currently licensed as GPL. Jim, Bruno, are you okay with relicensing closeout and close-stream as LGPLv2+?
They're both relatively thin wrappers. Fine by me.
Hi Eric,
case 'v': - /* FIXME - list a copyright blurb, as in GNU programs? */ - puts(VERSION); + vshShowVersion(ctl); exit(EXIT_SUCCESS);
The gnulib module closeout can automatically take care of this, but it is currently licensed as GPL. Jim, Bruno, are you okay with relicensing closeout and close-stream as LGPLv2+?
In gnulib we have a rule of thumb which says that anything that calls exit() or xmalloc() is likely to end up only in executables, not in libraries, and code in executables can just as well be relicensed under GPL instead of LGPL. In the libiconv and gettext packages, for example, the executables are all under GPL, although other parts of the package are under LGPL. Have you (and the management and lawyers behind libvirt) considered this approach for libvirt? I ask because 'closeout' may be only the beginning. Then comes 'xalloc', 'quotearg', and 'avltree-list', and at the end these high-value modules could be used by proprietary programs (assuming appropriate LGPL compliant packaging). We need a borderline between what can go LGPL and what needs to stay GPL, and the rule of thumb mentioned above is a good guiding line. Btw, for the modules 'closeout' and 'close-stream', a look at $ gitk lib/closeout.h lib/closeout.c lib/close-stream.h lib/close-stream.c reveals that you have to ask also Paul, not only Jim and me. Bruno
Bruno Haible wrote:
Hi Eric,
case 'v': - /* FIXME - list a copyright blurb, as in GNU programs? */ - puts(VERSION); + vshShowVersion(ctl); exit(EXIT_SUCCESS);
The gnulib module closeout can automatically take care of this, but it is currently licensed as GPL. Jim, Bruno, are you okay with relicensing closeout and close-stream as LGPLv2+?
In gnulib we have a rule of thumb which says that anything that calls exit() or xmalloc() is likely to end up only in executables, not in libraries, and code in executables can just as well be relicensed under GPL instead of LGPL.
Of course. Thanks for the reminder, Bruno. That is indeed a slippery slope. I was too hasty in saying "ok". Eric, one option is to use the GPLv3 for programs like virsh, then to have a second gnulib library that they would use.
In the libiconv and gettext packages, for example, the executables are all under GPL, although other parts of the package are under LGPL. Have you (and the management and lawyers behind libvirt) considered this approach for libvirt?
I ask because 'closeout' may be only the beginning. Then comes 'xalloc', 'quotearg', and 'avltree-list', and at the end these high-value modules could be used by proprietary programs (assuming appropriate LGPL compliant packaging). We need a borderline between what can go LGPL and what needs to stay GPL, and the rule of thumb mentioned above is a good guiding line.
On 10/29/2010 04:43 PM, Jim Meyering wrote: <snip>
Of course. Thanks for the reminder, Bruno. That is indeed a slippery slope. I was too hasty in saying "ok".
Eric, one option is to use the GPLv3 for programs like virsh, then to have a second gnulib library that they would use.
Cue "making it more difficult for packagers", and that extra bit harder for people wanting to figure out licensing for use with their app. ;> In this specific instance, probably the best route is the easiest one, and keep on using our existing (less optimal, but already license compatible) code. :)
participants (7)
-
Bruno Haible -
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
jclift＠redhat.com -
Jim Meyering -
Justin Clift