qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] fix/re-do query-command-line-options
Date: Tue, 28 Jan 2014 12:55:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Paolo Bonzini <address@hidden> 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.

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

> (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?

> (c) do not add any more QemuOpts options without a schema, and use
> -object instead.
>
> Then:
>
> (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?

> (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*.

> Do you agree?

It depends :)



reply via email to

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