From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAkcu-0008LM-Sb for qemu-devel@nongnu.org; Mon, 03 Oct 2011 11:40:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAkct-0008Mz-S4 for qemu-devel@nongnu.org; Mon, 03 Oct 2011 11:40:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48618) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAkct-0008Mm-GW for qemu-devel@nongnu.org; Mon, 03 Oct 2011 11:40:19 -0400 Date: Mon, 3 Oct 2011 17:41:18 +0200 From: "Michael S. Tsirkin" Message-ID: <20111003154117.GC20141@redhat.com> 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> <20111003141539.GC19689@redhat.com> <4E89CCF1.3030603@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E89CCF1.3030603@us.ibm.com> Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Michael Roth , qemu-devel@nongnu.org On Mon, Oct 03, 2011 at 09:55:45AM -0500, Anthony Liguori wrote: > How I see this all evolving in the future is that we would have a > formal protocol specification. From that spec, we would generate > Visitors. This would handle taking what's on the wire and building > an in-memory tree. If an ASN.1 sequence that isn't part of the spec > is passed, we should just silently discard it. > > I think the scenario above is that we have an array in the spec, but > the implementation no longer uses that array. Your concern is that > its inefficient to keep it in memory? > > I think there are two cases. The first is that that array is > required in the spec, but optional in our implementation and that > decision is made at run time. In this case, it needs to get entered > into memory. > > If the array is no longer needed at all in our implementation, we > can certainly annotate the protocol spec to skip it and not bring it > into memory. Maybe it's an internal spec annotation or something. > > All that said, this doesn't seem to be a terribly important problem to solve IMHO. This is not exactly the concern. Consider that when we see an optional field we do not recognize, we need to discard it. Now, the reason we get a field we do not recognize might be because someone is feeding us malformed data (to DOS us, or by mistake). If we just trust input we will allocate insane amounts of memory. This is why we should not rely on fields to have reasonable size in the input, we need to validate them. -- MST