From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFNqT-0001Kl-RN for qemu-devel@nongnu.org; Wed, 04 Apr 2012 06:53:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFNqP-0006dT-93 for qemu-devel@nongnu.org; Wed, 04 Apr 2012 06:53:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFNqP-0006dD-0p for qemu-devel@nongnu.org; Wed, 04 Apr 2012 06:53:41 -0400 Message-ID: <4F7C282E.6090309@redhat.com> Date: Wed, 04 Apr 2012 13:53:34 +0300 From: Dor Laor MIME-Version: 1.0 References: <4F7B610D.8000101@redhat.com> <20120404011843.GA2918@illuin> <4F7BFAEB.7070000@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call minutes April 3 Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Paolo Bonzini , qemu-devel@nongnu.org, KVM devel mailing list , Markus Armbruster On 04/04/2012 01:37 PM, Michael Roth wrote: > > On Apr 4, 2012 2:42 AM, "Paolo Bonzini" > wrote: > > > > Il 04/04/2012 03:18, Michael Roth ha scritto: > > > Attacking the IDL/schema side first is the more rationale approach. > From > > > there we can potentially generate ASN.1 BER/DER visitors for the > protocol > > > side, or potentially even just vmstate bindings as a start. I've > recently > > > started looking into the latter... it's completely feasible, the only > > > downside is it complicates the IDL due requiring support for a lot of > > > what are very much vmstate-specific items, but it should be possible to > > > do this in a manner where those annotations are self-contained and > > > ignorable if we opted to replace vmstate-style declarations. > > > > We can also keep the current vmstate descriptions, but access fields > > from the automatically-generated visitors instead of struct fields. > > This keeps the IDL simple. > > It may be worthwhile as an incremental step though, one nice thing about > automatically generated bindings is that with the QIDL Anthony > prototyped a while back we assume we serialize by default, so changes in > annotated structs automatically trigger changes in the generated > bindings unless you explicitly mark fields as immutable/derivable/etc, > which we can tie into the build or make check to automatically detect > and bring attention to changes in vmstate. This may be worth the effort > if we adopt the proposed 4 year migration support cycle for pc-1.0, > since that'll continue to rely on vmstate even after we move on to an > IDL and newer protocol. Beyond ASL/IDL I like to be sure that we're not just translating one format to other representation but instead we introduce some new functionality like: - Ability to negotiate the protocol version - Bi-direction data exchange, the sender will send data as a function of the target release - Include the machine type too - Synchronize the entire qemu cmdline and don't relay on management to set it up. - Along the way, deal w/ hotplug events. > > > > > Paolo > > >