Re: [Qemu-devel] fix/re-do query-command-line-options

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

 



Il 28/01/2014 12:55, Markus Armbruster ha scritto:
Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:

Il 28/01/2014 10:36, Markus Armbruster ha scritto:
I think the data you can usefully collect with this approach is
approximately the data getopt_long()[*] gets: list of named command line
options, and whether they take an argument.

You can use this data to fill in options not covered by QemuOpts.  This
is a definite improvement.

It still falls short of fully solving the command line introspection
problem.

However, I'm not into rejecting imperfect incremental improvements we
can have now in favor of perfect solutions we can maybe have some day.
Go right ahead with your incremental improvement!

It depends.  If we can agree on the following:

(a) do not add non-QemuOpts options (we haven't for a while)

That would mean we can't ever add an option that doesn't take an
argument again.

We can add it under an existing QemuOpts group or invent a new one (like we did for -rt or -msg).

However, we need to somehow stuff those into QemuOpts anyway, so
-readconfig / -writeconfig can cover them.

Yep.

(b) document the QemuOpts schema for -acpitable, -smbios, -netdev,
-net. These options validate the options with OptsVisitor, so we could
do without QemuOpts schema, but we know the schema won't bitrot
because we never remove suboptions.

-device?

-device already provides its own introspection via "qom-list-types" and "-device driver,?".

-object doesn't have an equivalent of "-device driver,?", but that's a separate problem.

(a) there is no need to cover non-QemuOpts options in
query-command-line-options.  libvirt can treat them as crystallized.

Some options are undef #ifdef.  That's actually a good idea, because it
permits finding out which options are available via command line
introspection.

Now, what if a non-QemuOpts option is under #ifdef?  I haven't
checked...  Even if there isn't one now, are we ready to give up the
ability to do that for good?

There are some:

- legacy slirp options -tftp/-bootp/-redir/-smb

- -enable-fips is what triggered this discussion, but we found another solution in Libvirt

- -tpmdev is enabled only if CONFIG_TPM, but its presence can be queried via qom-list-types too.

(b) documenting the schemata is not harder than what Amos proposed.

(c) schema inspection for objects remains a problem, but one that we
need to solve anyway so it doesn't affect query-command-line-options.

As long as we don't have such schema inspection, I'm rather reluctant to
reject alternative means to solve problems people have *now*.

Note the "doesn't affect query-command-line-options" part. Amos's patch do not solve the problem of which classes can be instantiated with -object, or of which properties can be used.

Paolo

Do you agree?

It depends :)


--
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]