From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn3VP-0007Il-TD for qemu-devel@nongnu.org; Wed, 21 May 2014 06:12:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn3VJ-0007S6-Mp for qemu-devel@nongnu.org; Wed, 21 May 2014 06:12:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn3VJ-0007Ry-E2 for qemu-devel@nongnu.org; Wed, 21 May 2014 06:12:09 -0400 Date: Wed, 21 May 2014 15:42:05 +0530 From: Amit Shah Message-ID: <20140521101205.GB32726@grmbl.mre> References: <20140521094407.GC2589@work-vm> <20140521095502.GA32726@grmbl.mre> <20140521100304.GD2589@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140521100304.GD2589@work-vm> Subject: Re: [Qemu-devel] [PATCH 01/18] migration: dump vmstate info as a json file for static analysis List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Juan Quintela , Markus Armbruster , Alexander Graf , qemu list , Paolo Bonzini , Andreas F?rber On (Wed) 21 May 2014 [11:03:04], Dr. David Alan Gilbert wrote: > * Amit Shah (amit.shah@redhat.com) wrote: > > The idea is to be able to take a qemu binary and compare with another > > binary; if only fields that are instantiated are used, various > > invocations will have to be tried to find devices that may have > > broken. > > > > An alternative way of checking only devices which have been added to > > the running machine can be done via a monitor command (or a parameter > > to the existing cmdline option). But I'm not sure if that'll be more > > useful than the current one. > > Or perhaps a way to dump that info and mask your checker with it if wanted? A 'blacklist' file, which stores names of sections that you're not interested in? > > > 2) 'fields_exists' is a weird naming to put in the json file - it's > > > a function pointer for determining if the field is going to be present; > > > maybe renaming as 'conditional' would make sense. > > > > Yea; I don't know if field_exists is going to be useful anyway. It's > > runtime info rather than static, so perhaps can just be dropped. > > Right now, anyway, the checker doesn't make use of this field at all. > > I think it's useful to have field_exists because it lets you know that it's > conditional, I just think it's weird naming it like that in the json, since > an entry in the json that says 'fields_exists: true' sounds like the field > always exists, which is the opposite of what it means. It's just a naming > thing here. On the name of the field, I doubt anyone will read the json file itself to get confused by it. Also, it stays true to what the field is called in the actual vmstate structs in qemu. On the usability of the field: it's like subsections: they may exist or not, but we should check them nevertheless on src and dest, and any difference should be flagged. Amit