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

[Kevin Wolf <kwolf@redhat.com>]

Am 14.03.2011 18:48, schrieb 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.

Do you have an example from your implementation for this?

I think the tricky part is that the valid fields depend on the block
driver. qcow2 wants another BlockDriverState as its image file; file
wants a file name; vvfat wants a directory name, FAT type and disk type;
and NBD wants a host name and a port, except if it uses a UNIX socket.

This is probably the most complex thing you can get, so I think it would
make a better example than a VNC configuration.

Kevin