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
