From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAl0h-00025q-Ig for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:05:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAl0g-0005vy-8h for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:04:55 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:56250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAl0f-0005vg-Vr for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:04:54 -0400 Received: by iagf6 with SMTP id f6so6450461iag.4 for ; Mon, 03 Oct 2011 09:04:52 -0700 (PDT) Message-ID: <4E89DCA7.6010909@codemonkey.ws> Date: Mon, 03 Oct 2011 11:02:47 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <20111003064653.GA15380@redhat.com> <4E89AFB4.8000103@us.ibm.com> <20111003132445.GB18920@redhat.com> <4E89BC1A.30208@codemonkey.ws> <20111003141140.GB19689@redhat.com> <4E89C9BA.8070404@us.ibm.com> <20111003152950.GB20141@redhat.com> <4E89D86D.2010201@codemonkey.ws> <20111003155814.GG20141@redhat.com> In-Reply-To: <20111003155814.GG20141@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Michael Roth , qemu-devel@nongnu.org On 10/03/2011 10:58 AM, Michael S. Tsirkin wrote: > On Mon, Oct 03, 2011 at 10:44:45AM -0500, Anthony Liguori wrote: >>>>> Specifically >>>>> the case where first field in a sequence tells >>>>> you the meaning of the following ones? >>>> >>>> Can you give me the example in ASN.1? >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>> >>> That would be a selection from CHOICE. >>> Note that CHOICE doesn't affect encoding on the wire: >>> BER just uses the underlying type. >> >> Ah, so that's a union value. I think we would have to decide how we >> wanted to model unions. > > IMHO it's easier to use if a visitor for the right type > is called, not a top level one for the union. > >> Presumably, the selected CHOICE is >> indicated by some other field? > > Exactly. Some function of some other field :) > >> I would think it's a good idea to >> use the type information to identify which selection of a CHOICE was >> chosen. > > Not sure what this means. We really need to look at the > serialized field to know which selection was chose. > In theory the field that dictates the meaning might come > after the choice, but I think we don't limit outselves > too much if we require it to come before in a sequence. Yeah, you can certainly open code it.. if (s->some_field == FOO) { visit_type_int(...); } else if (s->some_field == BAR) { visit_type_str(...); } Personally, I'm inclined to just go with that strategy unless it becomes pervasive. If so, I think it's worth abstracting to a higher level concept. What that means for having a multi-Visitor system is that the protocol layer would accept any valid choice and the Device layer would validate that the selected choice is valid based on the field contents. Regards, Anthony Liguori > > >> I had implemented a union type in the old glib branch but that was >> based on a struct with an enum element and then the appropriate >> value element. >> >> Regards, >> >> Anthony Liguori > > Yes, this seems limiting. >