Re: [Qemu-devel] [PATCH v4 1/3] vl: Add a flags to define parameters with optional arguments.

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

On 09/04/2015 01:55 PM, Stefan Weil wrote:
> Am 04.09.2015 um 21:42 schrieb Eric Blake:
>> On 09/04/2015 01:30 PM, Laurent Vivier wrote:
>>> The goal is to be able to use '-help' alone, or with
>>> a sub-section, i.e. '-help network,usb'.
>> Uggh. I hate reinventing the wheel.  We aren't using getopt_long_only();
>> but if we were, the ONLY way to specify optional arguments to a long
>> option is by using the = sign, and not by space separation.
>>
>> That is, '-help=network,usb' would work, but '-help network,usb' would
>> NOT be seen as arguments to -help.
>>
>> While I'd really rather we just use getopt_long_only(), that's a much
>> bigger change.  But we should at least mirror its semantics, because it
>> is VERY confusing to have subtly different command-line behavior than
>> most apps out there.
> 
> Wasn't there a plan for a version jump (QEMU v3) with the next release?

I don't know; but feature-wise, if MTTCG and introspection both land in
the next release, that would be major enough in my book to be worth
naming things 3.0 if people like it.

> 
> Then we could really go a step towards getopt_long_only
> and require options written like --help instead of -help.

getopt_long_only() is an awkward interface. Most apps should use
getopt_long() instead.  What getopt_long_only() does is allow you to use
'-long' or any unambiguous prefix instead of '--long', provided that
'-l' is not a short option.  Note that we have '-h' as an alias for
long-option help, we'd run into fixable issues (since getopt_long_only()
allows unambiguous abbreviations, getting rid of short -h would allow
'-h' to become unambiguous for long option '--help', as long as no other
long option starts with h [oops, we have -hda]; on top of that, you can
also explicitly list '--h' as a long option, which would then make it
take preference over any other substring of a longer name).  So it would
still be possible to switch to getopt_long_only() while still keeping
support for '-help' to work.

Meanwhile, where we'd run into trouble is the fact that '-m' is
different than '-machine'; if we use getopt_long(), then '-machine'
would break.

> Today both variants work, so we would have to remove
> support for the -help form.

Well, even if we don't remove support for '-help', we could at least
update our documentation to mention that '--long' forms already work,
and that they are the favored spelling (as we may want to eventually get
rid of -short forms down the road).  But I agree that gratuitously
breaking existing -short form command lines without ample warning time
is not the right approach to take, and don't know if we have given
enough warning, regardless of whether the next release is named 2.5 or 3.0.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]