qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] Memory API mutators


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/3] Memory API mutators
Date: Wed, 14 Sep 2011 14:46:49 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]