Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> As I've been waiting for QAPI review, I've been working on the design
> of a new mechanism to replace our current command line option handling
> (QemuOpts) with something that reuses the QAPI infrastructure.

I'm ignoring the connection to QAPI, because I'm still ignorant there.

> The 'QemuOpts' syntax is just a way to encode complex data structures.
> nic,model=virtio,macaddress=00:01:02:03:04:05' can be mapped directly
> to a C data structure.  This is exactly what QCFG does using the same
> JSON schema mechanism that QMP uses.
>
> The effect is that you describe a command line argument in JSON like so:
>
> { 'type': 'VncConfig',
>   'data': { 'address': 'str', '*password': 'bool', '*reverse': 'bool',
>             '*no-lock-key-sync': 'bool', '*sasl': 'bool', '*tls': 'bool',
>             '*x509': 'str', '*x509verify': 'str', '*acl': 'bool',
>             '*lossy': 'bool' } }
>
>
> You then just implement a C function that gets called for each -vnc
> option specified:
>
> void qcfg_handle_vnc(VncConfig *option, Error **errp)
> {
> }
>
> And that's it.  You can squirrel away the option such that they all
> can be processed later, you can perform additional validation and
> return an error, or you can implement the appropriate logic.
>
> The VncConfig structure is a proper C data structure.  The advantages
> of this approach compared to QemuOpts are similar to QAPI:
>
> 1) Strong typing means less bugs with lack of command line validation.
> In many cases, a bad command line results in a SEGV today.

Static typing, you mean.

> 2) Every option is formally specified and documented in a way that is
> both rigorous and machine readable.  This means we can generate high
> quality documentation in a variety of formats.

You make it sound like QemuOpts wouldn't specify options.  It does.
Where your proposal differs from QemuOpts, in my opinion, is that it
uses C types rather than QemuOpts' very own ad hoc type system, and is
more expressive, see your 6) below.

> 3) The command line parameters support full introspection.  This
> should provide the same functionality as Dan's earlier introspection
> patches.

Again, this isn't something QemuOpts could not do.  We just neglected to
make its option specification available outside QEMU, mostly because for
lack of consensus on what we want to expose there.

> 4) The 'VncConfig' structure also has JSON marshallers and the
> qcfg_handle_vnc() function can be trivially bridged to QMP.  This
> means command line oriented interfaces (like device_add) are better
> integrated with QMP.

Yes.

> 5) Very complex data types can be implemented.  We had some discussion
> of supporting nested structures with -blockdev.  This wouldn't work
> with QemuOpts but I've already implemented it with QCFG (blockdev
> syntax is my test case right now).  The syntax I'm currently using is
> -blockdev
> cache=none,id=foo,format.qcow.protocol.nbd.hostname=localhost where
> .' is used to reference sub structures.

We might want some syntactic sugar so that users don't have to repeat
format.qcow.protocol.nbd.FOO for every FOO they want to configure.

> 6) Unions are supported which means complex options like -net can be
> specified in the schema and don't require hand validation.
>
> I've got a spec written up at http://wiki.qemu.org/Features/QCFG.

Not reachable right now.

> Initial code is in my QAPI tree.
>
> I'm not going to start converting things until we get closer to the
> end of 0.15 and QAPI is fully merged.  My plan is to focus on this for
> 0.16 and do a full conversion for the 0.16 time frame using the same
> approach as QAPI.  That means that for 0.16, we would be able to set
> all command line options via QMP in a programmatic fashion with full
> support for introspection.
>
> I'm haven't yet closed on how to bridge this to qdev.  qdev is a big
> consumer of QemuOpts today.  I have some general ideas about what I'd
> like to do but so far, I haven't written anything down.

Glad you mention qdev.

qdev properties describe the configurable parts of qdev state objects.
A state object is a C struct.  The description is C data.  Poor man's
reflection.

qdev needs to parse and print a device's properties.  It uses QemuOpts
to parse NAME=VALUE,... option strings into a list of (NAME, VALUE), and
callbacks to parse the VALUEs.  Awkward, especially when you go QMP ->
option string -> qdev struct.

Yet another one: vmstate, which describes migratable parts of qdev state
objects.

Unlike these two, QCFG doesn't describe C structs, it generates them
from JSON specs.  If I understand your proposal correctly.  Hmm.

Can we avoid defining our data types in JSON rather than C?

Can we adopt *one* reflection mechanism?

> I wanted to share these plans early hoping to get some feedback and
> also to maybe interest some folks in helping out.

There's also QEMUOptionParameter, thankfully limited to block code.  Any
plans to cover that as well?


Hmm, my nitpicking and questioning may sound like I don't like the idea
of replacing QemuOpts.  That's actually not the case.