Just noticed that I hadn't replied to this yet. Sorry for the
long delay!
On Thu, May 12, 2016 at 09:46:25AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes:
[...]
> > ##
> > # @CpuDefinitionInfo:
> > #
> > # Virtual CPU definition.
> > #
> > # @name: the name of the CPU definition
> > # @runnable: #optional. whether the CPU model us usable with the
> > # current machine and accelerator. Omitted if we don't
> > # know the answer. (since 2.7)
> > # @unavailable-features: List of attributes that prevent the CPU
>
> Unless you drop the * sigil from '*unavailable-features', you need to
> insert #optional after the colon.
Fixed.
>
> > # model from running in the current host.
> > # (since 2.7)
> > #
> > # @unavailable-features is a list of QOM property names that
> > # represent CPU model attributes that prevent the CPU from running.
> > # If the QOM property is read-only, that means the CPU model can
> > # never run in the current host. If the property is read-write, it
> > # means that it MAY be possible to run the CPU model in the current
> > # host if that property is changed. Management software can use it
> > # as hints to suggest or choose an alternative for the user, or
> > # just to generate meaningful error messages explaining why the CPU
> > # model can't be used.
> > #
> > # Since: 1.2.0
> > ##
>
> Better.
>
> Next issue: how @runnable and @unavailable-features are related isn't
> fully documented. Here's my guess:
>
> Combinations possible? @runnable
> @unavailable-features absent false true
> absent yes ? ?
> present, empty ? ? ?
> present, non-empty ? yes no
unavailable-features should be present only if runnable is false.
It may be absent or empty if the architecture code still doesn't
provide detailed info.
Once we have additional architectures implementing the new
fields, we can consider requiring unavailable-features to be
always present (and non-empty) if runnable is false.
In other words:
Combinations possible? @runnable
@unavailable-features absent false true
absent yes yes[1] yes
present, empty no yes[1] no
present, non-empty no yes no
[1] I would like it to be "no", but I prefer to make it mandatory
only after we get some experience with other architectures.
I'm making the following changes to the documentation:
# Virtual CPU definition.
#
# @name: the name of the CPU definition
-# @runnable: #optional. whether the CPU model us usable with the
+# @runnable: #optional Whether the CPU model us usable with the
# current machine and accelerator. Omitted if we don't
# know the answer. (since 2.7)
-# @unavailable-features: List of attributes that prevent the CPU
-# model from running in the current host.
+# @unavailable-features: #optional List of attributes that prevent
+# the CPU model from running in the current
+# host. Present only if @runnable is false.
# (since 2.7)
#
# @unavailable-features is a list of QOM property names that
--
Eduardo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list