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

[Kevin Wolf <kwolf@redhat.com>]

Am 15.03.2011 14:27, schrieb Anthony Liguori:
> 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' } }

What would this look like in the generated C code? A union of
differently typed pointers?

Are format drivers still contained in a single C file in block/ that is
enabled just by compiling it in or does the block layer now have to know
about all available drivers and the options they provide?

>> 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 :-)

This is exactly what makes it interesting. :-)

Kevin