Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options
Ping? There doesn't seem to have been any decision about whether
changing the -help output was OK or not.
Patchwork url: http://patchwork.ozlabs.org/patch/169798/
-- PMM
On 9 July 2012 12:52, Peter Maydell peter.mayd...@linaro.org wrote:
For command line options which permit '?' meaning 'please list the
permitted values', add support for 'help' as a synonym, by abstracting
the check out into a helper function.
Update the documentation to use 'help' rather than '?', since '?'
is a shell metacharacter and thus prone to fail confusingly if there
is a single character filename in the current working directory and
the '?' has not been escaped. It's therefore better to steer users
towards 'help', though '?' is retained for backwards compatibility.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Patch is based on grepping the source for '?' and ?; I think I've
caught everything that needed changing but it's possible I missed
something.
NB: the bsd-user patch isn't compile tested since I don't have a BSD box.
arch_init.c |4 ++--
blockdev.c| 10 +-
bsd-user/main.c |6 +++---
hw/mips_jazz.c|2 +-
hw/qdev-monitor.c |2 +-
hw/watchdog.c |2 +-
linux-user/main.c |4 ++--
net.c |3 ++-
qemu-common.h | 16
qemu-doc.texi |2 +-
qemu-ga.c |2 +-
qemu-img.c|4 ++--
qemu-options.hx | 32
qemu-timer.c |2 +-
vl.c |4 ++--
15 files changed, 56 insertions(+), 39 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index a9e8b74..e8e6f80 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -602,7 +602,7 @@ void select_soundhw(const char *optarg)
{
struct soundhw *c;
-if (*optarg == '?') {
+if (is_help_option(optarg)) {
show_valid_cards:
printf(Valid sound card names (comma separated):\n);
@@ -610,7 +610,7 @@ void select_soundhw(const char *optarg)
printf (%-11s %s\n, c-name, c-descr);
}
printf(\n-soundhw all will enable all of the above\n);
-exit(*optarg != '?');
+exit(!is_help_option(optarg));
}
else {
size_t l;
diff --git a/blockdev.c b/blockdev.c
index 9e0a72a..7810cd7 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -398,11 +398,11 @@ DriveInfo *drive_init(QemuOpts *opts, int
default_to_scsi)
#endif
if ((buf = qemu_opt_get(opts, format)) != NULL) {
- if (strcmp(buf, ?) == 0) {
- error_printf(Supported formats:);
- bdrv_iterate_format(bdrv_format_print, NULL);
- error_printf(\n);
- return NULL;
+if (is_help_option(buf)) {
+error_printf(Supported formats:);
+bdrv_iterate_format(bdrv_format_print, NULL);
+error_printf(\n);
+return NULL;
}
drv = bdrv_find_whitelisted_format(buf);
if (!drv) {
diff --git a/bsd-user/main.c b/bsd-user/main.c
index cd33d65..0aad752 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -681,7 +681,7 @@ static void usage(void)
-g port wait gdb connection to port\n
-L path set the elf interpreter prefix (default=%s)\n
-s size set the stack size in bytes (default=%ld)\n
- -cpu modelselect CPU (-cpu ? for list)\n
+ -cpu modelselect CPU (-cpu help for list)\n
-drop-ld-preload drop LD_PRELOAD for target process\n
-E var=value sets/modifies targets environment
variable(s)\n
-U varunsets targets environment variable(s)\n
@@ -825,8 +825,8 @@ int main(int argc, char **argv)
qemu_uname_release = argv[optind++];
} else if (!strcmp(r, cpu)) {
cpu_model = argv[optind++];
-if (strcmp(cpu_model, ?) == 0) {
-/* XXX: implement xxx_cpu_list for targets that still miss it */
+if (is_help_option(cpu_model)) {
+/* XXX: implement xxx_cpu_list for targets that still miss
it */
#if defined(cpu_list)
cpu_list(stdout, fprintf);
#endif
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index bf1b799..db927f1 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -239,7 +239,7 @@ static void mips_jazz_init(MemoryRegion *address_space,
dp83932_init(nd, 0x80001000, 2, get_system_memory(), rc4030[4],
rc4030_opaque, rc4030_dma_memory_rw);
break;
-} else if (strcmp(nd-model, ?) == 0) {
+} else if (is_help_option(nd-model)) {
fprintf(stderr, qemu: Supported NICs: dp83932\n);
exit(1);
} else {
diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index 7915b45..d777a20 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -138,7 +138,7 @@ int
Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options
On 07/09/2012 05:52 AM, Peter Maydell wrote:
For command line options which permit '?' meaning 'please list the
permitted values', add support for 'help' as a synonym, by abstracting
the check out into a helper function.
Update the documentation to use 'help' rather than '?', since '?'
is a shell metacharacter and thus prone to fail confusingly if there
is a single character filename in the current working directory and
the '?' has not been escaped. It's therefore better to steer users
towards 'help', though '?' is retained for backwards compatibility.
I like the idea, but this may cause grief for libvirt, which basically does:
const char *help; // = output of 'qemu -h'
if (strstr(help, -device driver,?)) {
/* Cram together all device-related queries into one invocation;
* the output format makes it possible to distinguish what we
* need. With qemu 0.13.0 and later, unrecognized '-device
* bogus,?' cause an error in isolation, but are silently ignored
* in combination with '-device ?'. Upstream qemu 0.12.x doesn't
* understand '-device name,?', and always exits with status 1 for
* the simpler '-device ?', so this function is really only useful
* if -help includes device driver,?. */
cmd = virCommandNewArgList(qemu,
-device, ?,
-device, pci-assign,?,
-device, virtio-blk-pci,?,
-device, virtio-net-pci,?,
-device, scsi-disk,?,
NULL);
}
That is, we are filtering based on the explicit presence of a literal
'?' in the help output to determine whether we can further filter based
on '-device device,?' queries without confusing qemu or libvirt;
changing the 'help' output means that old libvirt with new qemu won't
run the extra queries (as if it had been targeting qemu 0.12.x), even
though the older spelling of the query would still work.
If that is not a concern (that is, if you are willing to state that use
of newer qemu is intended to be coupled with newer libvirt that has been
taught to use 'help' instead of '?'), then this patch is probably fine.
The alternative is to update 'qemu -h' output to mention both forms,
rather than completely eradicating the ? form from documentation.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options
On 9 July 2012 13:07, Eric Blake ebl...@redhat.com wrote: That is, we are filtering based on the explicit presence of a literal '?' in the help output to determine whether we can further filter based on '-device device,?' queries without confusing qemu or libvirt; changing the 'help' output means that old libvirt with new qemu won't run the extra queries (as if it had been targeting qemu 0.12.x), even though the older spelling of the query would still work. If that is not a concern (that is, if you are willing to state that use of newer qemu is intended to be coupled with newer libvirt that has been taught to use 'help' instead of '?'), then this patch is probably fine. My personal position would be that people who parse -help output deserve to get bitten, but I don't get to make that call :-) -- PMM
Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options
On 07/09/2012 06:10 AM, Peter Maydell wrote: On 9 July 2012 13:07, Eric Blake ebl...@redhat.com wrote: That is, we are filtering based on the explicit presence of a literal '?' in the help output to determine whether we can further filter based on '-device device,?' queries without confusing qemu or libvirt; changing the 'help' output means that old libvirt with new qemu won't run the extra queries (as if it had been targeting qemu 0.12.x), even though the older spelling of the query would still work. If that is not a concern (that is, if you are willing to state that use of newer qemu is intended to be coupled with newer libvirt that has been taught to use 'help' instead of '?'), then this patch is probably fine. My personal position would be that people who parse -help output deserve to get bitten, but I don't get to make that call :-) Obviously, newer libvirt can just proceed to try '-device device,help' rather than attempting to parse -h output in the first place (that is, making this change will not cause undue grief to libvirt 0.10.0, because it's a very short patch to teach libvirt.git to parse this new scheme, even without relying on -h output). That is, my concern is not about what future libvirt will be fixed to do, but about the existing interaction of old libvirt with qemu (libvirt 0.9.13 + qemu 1.2 would fail to take full advantage of the qemu 1.2 features because of the change in the -h output that libvirt 0.9.13 was hard-coded to expect). And yes, I agree that libvirt has been bitten more than once because it tries to parse unstable -h output, but that is only because qemu has never provided anything more stable and more machine-parseable than -h output, even though the topic has come up several times in the past. For example, we still don't have a way to run 'query-commands' to see what the QMP monitor will support without first creating a dummy guest. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options
On Mon, Jul 09, 2012 at 06:07:48AM -0600, Eric Blake wrote:
On 07/09/2012 05:52 AM, Peter Maydell wrote:
For command line options which permit '?' meaning 'please list the
permitted values', add support for 'help' as a synonym, by abstracting
the check out into a helper function.
Update the documentation to use 'help' rather than '?', since '?'
is a shell metacharacter and thus prone to fail confusingly if there
is a single character filename in the current working directory and
the '?' has not been escaped. It's therefore better to steer users
towards 'help', though '?' is retained for backwards compatibility.
I like the idea, but this may cause grief for libvirt, which basically does:
const char *help; // = output of 'qemu -h'
if (strstr(help, -device driver,?)) {
/* Cram together all device-related queries into one invocation;
* the output format makes it possible to distinguish what we
* need. With qemu 0.13.0 and later, unrecognized '-device
* bogus,?' cause an error in isolation, but are silently ignored
* in combination with '-device ?'. Upstream qemu 0.12.x doesn't
* understand '-device name,?', and always exits with status 1 for
* the simpler '-device ?', so this function is really only useful
* if -help includes device driver,?. */
cmd = virCommandNewArgList(qemu,
-device, ?,
-device, pci-assign,?,
-device, virtio-blk-pci,?,
-device, virtio-net-pci,?,
-device, scsi-disk,?,
NULL);
}
That is, we are filtering based on the explicit presence of a literal
'?' in the help output to determine whether we can further filter based
on '-device device,?' queries without confusing qemu or libvirt;
changing the 'help' output means that old libvirt with new qemu won't
run the extra queries (as if it had been targeting qemu 0.12.x), even
though the older spelling of the query would still work.
If that is not a concern (that is, if you are willing to state that use
of newer qemu is intended to be coupled with newer libvirt that has been
taught to use 'help' instead of '?'), then this patch is probably fine.
The alternative is to update 'qemu -h' output to mention both forms,
rather than completely eradicating the ? form from documentation.
Regardless of what QEMU does here, I think we should change libvirt's
handling of this arg. I think we can probably just skip that check, and
run 'qemu -device XXX,?' unconditionally and then handle any error that
we get back from old QEMU.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options
Eric Blake ebl...@redhat.com writes: On 07/09/2012 06:10 AM, Peter Maydell wrote: On 9 July 2012 13:07, Eric Blake ebl...@redhat.com wrote: That is, we are filtering based on the explicit presence of a literal '?' in the help output to determine whether we can further filter based on '-device device,?' queries without confusing qemu or libvirt; changing the 'help' output means that old libvirt with new qemu won't run the extra queries (as if it had been targeting qemu 0.12.x), even though the older spelling of the query would still work. If that is not a concern (that is, if you are willing to state that use of newer qemu is intended to be coupled with newer libvirt that has been taught to use 'help' instead of '?'), then this patch is probably fine. My personal position would be that people who parse -help output deserve to get bitten, but I don't get to make that call :-) Obviously, newer libvirt can just proceed to try '-device device,help' rather than attempting to parse -h output in the first place (that is, making this change will not cause undue grief to libvirt 0.10.0, because it's a very short patch to teach libvirt.git to parse this new scheme, even without relying on -h output). That is, my concern is not about what future libvirt will be fixed to do, but about the existing interaction of old libvirt with qemu (libvirt 0.9.13 + qemu 1.2 would fail to take full advantage of the qemu 1.2 features because of the change in the -h output that libvirt 0.9.13 was hard-coded to expect). And yes, I agree that libvirt has been bitten more than once because it tries to parse unstable -h output, but that is only because qemu has never provided anything more stable and more machine-parseable than -h output, even though the topic has come up several times in the past. For example, we still don't have a way to run 'query-commands' to see what the QMP monitor will support without first creating a dummy guest. Yes, several attempts to provide something real useful have been shot down in favor of something hypothetical perfect. Thus, libvirt has no choice but working with the (poor) tools we give it: version number, try and see whether it fails, help output. Try and see can be slow, and there have been cases where you can't easily see whether it fails. Version number breaks down for backports. Help breaks down when the help text changes. Perhaps the following could reduce breakage. Say the feature to be tested appeared in fully usable form in upstream version X. If the version number is at least X, assume we have the feature. Else, if detecting a backport of the feature is worth it, check the help output for a feature signature. That way, your feature test becomes immune to future help changes. Downside, it becomes vulnerable to features vanishing in the future. But QEMU shouldn't do that to you without sufficient prior notice.
