Re: [Qemu-devel] [PATCH 6/7] slirp: Add description of new "dhcpvendopt" suboption to the help and man page

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 04/30/2014 04:13 AM, Fedor Lyakhov wrote:
>
>>>
>>> Rather than inventing YET ANOTHER command line quoting idiom in order to
>>> cram multiple strings into one option, can you instead manage to rework
>>> things so that the user can pass multiple dhcpvendopt= options, one per
>>> string?  That is, dhcpvendopt=tag1:value1\;tag2:value2 is ad-hoc, while
>>> dhcpvendopt=tag1=value1,dhcpvendopt=tag2=value2 could reuse existing
>>> machinery.
>> 
>> Thanks for your suggestion, it is very reasonable. I'll do that and
>> re-send the series. BTW, double '=' seems a bit odd - is it really
>> used this way in some other option? If not, I think it would be more
>> convenient to use multiple options with "dhcpvendopt=tag1:value1"
>> format instead. Also I'm not very familiar with QEMU cmdline option
>> design, so I'd appreciate a hint on existing "multi-option".
>
> name=tag=value vs. name=tag:value makes no difference to me; either is
> equally friendly to the shell and we are guaranteed that the 'tag'
> portion of the string will not contain = or :.  Your choice (sounds like
> you want ':').
>
> As for doing multi-options, I know it's wired up in QemuOpts, but I'm
> not quite sure of a good example of the actual C code usage.  I seem to
> recall that '-numa $node,cpus=1,cpus=3' is a valid way of creating a
> node that uses a disjoint set of cpu ids, so maybe that's where to start
> looking for pre-existing practice.  Maybe someone else can chime in.

I remember the -numa discussion, too, but it apparently hasn't produced
actual code: -numa is still parsed ad hoc.

QemuOpts accepts two syntaxes: key=value,... used for command line
option arguments, and file format used by -readconfig / writeconfig,
which is patterned after git-config / Windows INI.

Repeating keys to express lists is established practice in git-config.
Doing lists that way is very much preferred over inventing yet another
ad hoc list syntax.

The QemuOpts interface doesn't provide convenient ways to deal with
list-valued parameters, probably because there hasn't been a user, yet.
All we got is qemu_opt_foreach().  If you have a user, but difficulties
extending QemuOpts, ask for help.  git-log util/qemu-option.c should
give you an idea whom to ask.