[Top][All Lists]

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

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

From: Anthony Liguori
Subject: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling
Date: Mon, 14 Mar 2011 12:48:55 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

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.


Anthony Liguori

reply via email to

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