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

[Anthony Liguori <anthony@codemonkey.ws>]

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

Yes:

typedef enum BlockdevFormatKind {
     BFK_PROBE = 0,
     BFK_RAW = 1,
     BFK_QCOW2 = 2,
     BFK_QED = 3,
} BlockdevFormatKind;

typedef struct BlockdevFormat {
     BlockdevFormatKind kind;
     union {
         struct ProbeFormat * probe;
         struct RawFormat * raw;
         struct Qcow2Format * qcow2;
         struct QedFormat * qed;
     };
     struct BlockdevFormat * next;
} BlockdevFormat;

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

Yes, everything is contained within a single file.  In terms of build 
dependencies, it's really just a call about what matters to you.  You 
can have the block open take a BlockdevFormat which means the block 
layer doesn't need to know about specific formats.

Regards,

Anthony Liguori

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