From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ubtif-0006CP-4v for qemu-devel@nongnu.org; Mon, 13 May 2013 10:27:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ubtia-0006Mw-3Q for qemu-devel@nongnu.org; Mon, 13 May 2013 10:27:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UbtiZ-0006Mk-SN for qemu-devel@nongnu.org; Mon, 13 May 2013 10:27:12 -0400 Date: Mon, 13 May 2013 16:27:05 +0200 From: Kevin Wolf Message-ID: <20130513142705.GE6419@dhcp-200-207.str.redhat.com> References: <1367221335-22777-1-git-send-email-stefanha@redhat.com> <1367221335-22777-3-git-send-email-stefanha@redhat.com> <518DC2C6.5030500@redhat.com> <20130513082811.GB6419@dhcp-200-207.str.redhat.com> <5190E30E.40005@redhat.com> <20130513130931.GC6419@dhcp-200-207.str.redhat.com> <20130513091858.54c4e4e6@redhat.com> <5190F534.40806@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5190F534.40806@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 2/3] block: add block-backup QMP command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Fam Zheng , Wenchao Xia , qemu-devel@nongnu.org, Luiz Capitulino , imain@redhat.com, Stefan Hajnoczi , pbonzini@redhat.com, dietmar@proxmox.com Am 13.05.2013 um 16:14 hat Eric Blake geschrieben: > On 05/13/2013 07:18 AM, Luiz Capitulino wrote: > >>>> Luiz, any idea how to do something like this, a QAPI enum with values > >>>> that are determined at runtime? Especially with respect to the coming > >>>> schema introspection? > >>> > >>> Or maybe we make the 'enum' list ALL possible types, but then add a > >>> query-* command that returns an array of only those enum values that are > >>> supported. Introspection would see all types, but the query command > >>> would be the useful variant that is runtime-dependent. > > > > Agreed. This is a capability, and we're adding query- commands to query > > capabilities. > > > >> Then is there any advantage in making it an enum in the first place? > > > > Eric is in a better position to answer this, but the fact that this can > > be queried isn't a strong pro for having it? > > Hmm, you raise an interesting point - if we have a query-block-formats > command that returns an array of strings, then keep 'str' everywhere > else a format is required, that is no different for what is sent over > the wire compared to a query-block-formats that returns an array of > 'BlockFormat' enum values, with the enum showing all possible formats > (even if support wasn't compiled in), and with 'BlockFormat' everywhere > else. Introspection-wise, you'd have to know that you call > query-block-formats instead of introspecting on the type of the format > argument, but information-wise, there's no loss of details if the query- > command provides the runtime list, and the remaining commands stick with > 'str'. I still think an enum is a bit nicer from the type-safety > aspect, but I'm finding it hard to envision any scenario where libvirt > would have to resort to introspection if we have a query-block-formats > in place, and thus am not opposed to your idea of avoiding the enum. I think long term we'll need a dynamic schema anyway. As we go forward with modularisation and putting things into shared libraries, we'll have modules that add support for commands, enum values, etc. Providing the full list of theoretically available elements (i.e. what would be there, if everything was compiled and all modules were loaded) would probably implement the spec for the introspection interfaces by the letter, but just give useless information. Callers want to know what's really there. If we're going to have a query-* command for everything, then we don't need introspection at all. I would however prefer having the uniform schema introspection and building the schema at runtime instead of many separate query-* commands. Kevin