qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 6/7] slirp: Add description of new "dhcpvendopt"


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 6/7] slirp: Add description of new "dhcpvendopt" suboption to the help and man page
Date: Wed, 30 Apr 2014 07:17:37 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

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.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]