From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3nvf-0007rj-UZ for qemu-devel@nongnu.org; Wed, 14 Sep 2011 07:47:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3nvb-0004wf-2n for qemu-devel@nongnu.org; Wed, 14 Sep 2011 07:46:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3nva-0004wT-Qf for qemu-devel@nongnu.org; Wed, 14 Sep 2011 07:46:55 -0400 Message-ID: <4E709429.4050300@redhat.com> Date: Wed, 14 Sep 2011 14:46:49 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1315992222-24069-1-git-send-email-avi@redhat.com> <4E7078B4.6020203@redhat.com> <4E708180.1050201@siemens.com> In-Reply-To: <4E708180.1050201@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/3] Memory API mutators List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , "qemu-devel@nongnu.org" On 09/14/2011 01:27 PM, Jan Kiszka wrote: > >> > >> Avi Kivity (3): > >> memory: introduce memory_region_set_enabled() > >> memory: introduce memory_region_set_address() > >> memory: optimize empty transactions due to mutators > >> > >> memory.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++--------- > >> memory.h | 28 +++++++++++++++++++++++++++ > >> 2 files changed, 82 insertions(+), 10 deletions(-) > >> > > Whatever the outcome is (tons of memory_region_set/get_X functions or > huge attribute structures + set/get_attributes), it should be consistent > for all attributes of a memory region. And there should be only one way > of doing this. Why just one way? Different users may have different patterns. Of course internally one will be implemented on top of the other. > I think the decision multiple set/get vs. attribute struct depends on > some (estimated) usage stats: How many call sites will access multiple > attributes in one run and how may will only manipulate a single? > There won't be that many call sites to have real statistics. Let's just go with the individual accessors and see. When the entire tree is converted (including the already-converted sites that need revisiting to use this) we can see how it looks and update the API. -- error compiling committee.c: too many arguments to function