From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34350 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzUkC-0000lP-Io for qemu-devel@nongnu.org; Tue, 15 Mar 2011 09:57:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PzUkA-0007G3-9S for qemu-devel@nongnu.org; Tue, 15 Mar 2011 09:57:04 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:43081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PzUkA-0007Fo-6K for qemu-devel@nongnu.org; Tue, 15 Mar 2011 09:57:02 -0400 Received: by iwl42 with SMTP id 42so672950iwl.4 for ; Tue, 15 Mar 2011 06:57:01 -0700 (PDT) Message-ID: <4D7F702A.2070007@codemonkey.ws> Date: Tue, 15 Mar 2011 08:56:58 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling References: <4D7E5507.8010205@codemonkey.ws> <4D7F3AC2.1040309@redhat.com> <4D7F6936.3050607@codemonkey.ws> <4D7F6D91.60605@redhat.com> In-Reply-To: <4D7F6D91.60605@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Chris Wright , Adam Litke , qemu-devel , Stefan Hajnoczi , Markus Armbruster 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 >