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