qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling
Date: Tue, 15 Mar 2011 08:27:18 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]