Eric Blake <ebl...@redhat.com> 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.
