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

[Eduardo Habkost]

On Wed, Feb 27, 2013 at 11:04:08AM -0600, Anthony Liguori wrote:
> Eduardo Habkost <ehabkost at redhat.com> writes:
> 
> > On Wed, Feb 27, 2013 at 04:57:15PM +0100, Paolo Bonzini wrote:
> >> Il 27/02/2013 16:42, Anthony Liguori ha scritto:
> >> > There's such thing as list support in QemuOpts.  The only way
> >> > QemuOptsVisitor was able to implement it was to expose QemuOpts publicly
> >> > via options_int.h and rely on a implementation detail.
> >> > 
> >> > There are fixed types supported by QemuOpts.  It just so happens that
> >> > whenever qemu_opt_set() is called, instead of replacing the last
> >> > instance, the value is either prepended or appended in order to
> >> > implement a replace or set-if-unset behavior.
> >> 
> >> Fair enough.  Nobody said the implementation is pretty.
> >> 
> >> > If we want to have list syntax, we need to introduce first class support
> >> > for it.  Here's a simple example of how to do this.
> >> 
> >> If it is meant as a prototype only, and the final command-line syntax
> >> would be with repeated keys, that's okay.  I think that Eduardo/Markus/I
> >> are focusing on the user interface, you're focusing in the implementation.
> >> 
> >> In the meanwhile, however, it seems to me that Eduardo can use
> >> QemuOptsVisitor---which can also hide the details and provide type safety.
> >
> > Whatever I use to implement it, I still need to know how the
> > command-line syntax will look like, because we need to tell libvirt
> > developers how they should write the QEMU command-line.
> 
> Command line syntax is not committed until it appears in a release.
> libvirt *should not* assume any specific syntax until the 1.5 release
> ships.

I am just talking about communication with libvirt developers.
Developers surely write code and test their work in progress using
unreleased QEMU code, instead of waiting for an official release. Nobody
suggested releasing a libvirt version that relies on an unreleased QEMU
feature.

-- 
Eduardo