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

[Anthony Liguori]

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.

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.

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.

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

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.

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.

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

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

Regards,

Anthony Liguori