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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/15/2011 05:09 AM, Kevin Wolf wrote:
>> 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?

It's not exhaustive as I'm only using this for testing but here's what 
I've been working with:

{ 'type': 'ProbeProtocol', 'data': { 'unsafe': 'bool', 'filename': 'str' } }

{ 'type': 'FileProtocol', 'data': { 'filename': 'str' } }

{ 'type': 'HostDeviceProtocol', 'data': { 'device': 'str' } }

{ 'type': 'NbdProtocol', 'data': { 'hostname': 'str', 'port': 'int' } }

{ 'union': 'BlockdevProtocol',
   'data': { 'probe': 'ProbeProtocol', 'file': 'FileProtocol',
             'host-dev': 'HostDeviceProtocol', 'nbd': 'NbdProtocol' } }

{ 'type': 'ProbeFormat', 'data': { '*unsafe': 'bool', 'protocol': 
'BlockdevProtocol' } }

{ 'type': 'RawFormat', 'data': { 'protocol': 'BlockdevProtocol' } }

{ 'type': 'Qcow2Format',
   'data': { 'protocol': 'BlockdevProtocol',
             '*backing-file': 'BlockdevFormat' } }

{ 'type': 'QedFormat',
   'data': { 'protocol': 'BlockdevProtocol',
             '*backing-file': 'BlockdevFormat',
             '*copy-on-read': 'bool' } }

{ 'union': 'BlockdevFormat',
   'data': { 'probe': 'ProbeFormat', 'raw': 'RawFormat',
             'qcow2': 'Qcow2Format', 'qed': 'QedFormat' } }

{ 'enum': 'BlockdevCacheSetting',
   'data': [ 'none', 'writethrough', 'writeback' ] }

{ 'type': 'BlockdevConfig',
   'data': { 'id': 'str',
             'format': 'BlockdevFormat',
             '*cache': 'BlockdevCacheSetting',
             '*device': 'str' } }

{ 'option': 'blockdev', 'data': 'BlockdevConfig', 'implicit': 'id' }

Choosing a union is implicit in selecting the union value.  This was 
done to simplify the command line.  Here are some examples:

# create a blockdev using probing
-blockdev my-image.qcow2,id=ide0-hd0

# create a blockdev using probing without relying on implicit keys and 
allowing unsafe probing
-blockdev 
format.probe.unsafe=on,format.probe.protocol.file.filename=my-image.qcow2,id=ide0-hd0

# create a blockdev using qcow2 over NBD with a qed backing file
-blockdev format.qcow2.protocol.nbd={hostname=localhost,port=1025},\
                 
format.qcow2.backing-file.format.qed.protocol.nbd={hostname=localhost,port=1026},\
                 id=ide0-hd0

It looks less awkward in config file format:

[blockdev]
id = "ide0-hd0"
format.qcow2.protocol.nbd.hostname = localhost
format.qcow2.protocol.nbd.port = 1025
format.qcow2.backing-file.format.qed.protocol.nbd.hostname = localhost
format.qcow2.backing-file.format.qed.protocol.nbd.port = 1026

And with a syntax this complex, errors are important.  Here are some 
examples of Error messages:

#./test-qcfg format.qcow2.file.filename="image.img",id=ide0-hd0
-blockdev: Parameter 'format.qcow2.protocol' is missing

# ./test-qcfg 
format.qcow2.protocol.file.filename="image.img",format.qcow3.backing-file.format.qcow2.protocol.file.filename="foo.img",id=ide0-hd0
-blockdev: Invalid parameter 
'format.qcow3.backing-file.format.qcow2.protocol.file.filename'

#./test-qcfg 
format.qcow2.protocol.file.filename="image.img",id=ide0-hd0,cache=no-thank-you
-blockdev: Enum 'cache' with value 'no-thank-you' is invalid for type 
'BlockdevCacheSetting'

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

Yes, it's all handled with a new union type.

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

Yup, that's been what I've been using to prototype all of this.  I 
didn't it in the mail because it's rather complex :-)

Regards,

Anthony Liguori

> Kevin
>