Re: [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option

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

 



On Fri, Feb 22, 2013 at 11:04:24AM +0100, Markus Armbruster wrote:
> Markus Armbruster <armbru@xxxxxxxxxx> writes:
> 
> > Anthony Liguori <anthony@xxxxxxxxxxxxx> writes:
> >
> >> Markus Armbruster <armbru@xxxxxxxxxx> writes:
> >>
> >>> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes:
> >>>
> >>>> This allows "," to be used a separator between each CPU range.  Note
> >>>> that commas inside key=value command-line options have to be escaped
> >>>> using ",,", so the command-line will look like:
> >>>>
> >>>>   -numa node,cpus=A,,B,,C,,D
> >>>
> >>> This is really, really ugly, and an embarrassment to document.  Which
> >>> you didn't ;)
> >>>
> >>> What about
> >>>
> >>>     -numa node,cpus=A,cpus=B,cpus=C,cpus=D
> >>>
> >>> Yes, QemuOpts lets you do that.  Getting all the values isn't as easy as
> >>> it could be (unless you use Laszlo's opt-visitor), but that could be
> >>> improved.
> >>
> >> No more of this.
> >>
> >>  -numa node,cpus=A:B:C:D 
> >>
> >> if you want to express a list.
> >
> > Okay for command line and human monitor, just don't let it bleed into
> > QMP.
> 
> Footnotes:
> 
> 1. Using colons for lists works only as long as the list elements don't
> contain colons.  Fine for numbers.  No good for filenames, network
> addresses, ...
> 
> 2. QemuOpts helped us reduce the number of ad hoc option parsers,
> improving consistency and error messages quite a bit.  Having every user
> of colon lists roll their own ad hoc parser slides back into the hole
> that motivated QemuOpts.  Let's try to avoid that, please.
> 
> 3. The existing QemuOpts syntax for list-valued options (repeating the
> option) doesn't have either of these problems.

The problem here seems to be that we want to reuse option parsing code,
but the only reusable syntax we have for command-line options today is
awful (at least for representing lists).

So our only options seem to be: 1) accept some ugliness and things like
"A,,B,,C" or "cpus=A,cpus=B,cpus=C"; 2) write ad hoc option parsers; 3)
define/choose a new reusable syntax.

We already have at least 2 better ways to represent config data (config
files and QMP+JSON), but why do we insist in using command-line options
with an awful syntax for everything?

-- 
Eduardo

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]