Re: [PATCH] memory: transaction API

[Avi Kivity <avi@redhat.com>]

On 07/21/2011 03:09 PM, Jan Kiszka wrote:
> >
> >  Why? just stick a _begin() and _commit() at the start and end of the
> >  update_mapping() function.  It's an optional API, for simple cases (like
> >  mapping a BAR) you don't have to use it.
>
> begin
> delete old
> free old
> create new
> add new
> end
>
> vs.
>
> update
>

The problem is that "update" can change lots of things.  offset, size, 
whether it's mmio or RAM, read-onlyness, even the wierd things like 
coalesced mmio.  So it's either a function with 324.2 parameters (or a 
large struct), or it's a series of functions with demarcation as to 
where the update begins and ends.

> >
> >
> >>  Do we have transactional scenarios during runtime where multiple memory
> >>  regions are reconfigured?
> >
> >  Both cirrus and 440fx PAM, I believe.  They don't check for the "no
> >  change" condition (at least, not completely) and instead override the
> >  previous mapping.
>
> That's the job of the memory mapping core IIUC.

In my opinion, too.  Devices should be dead simple.

> But it can only be done
> efficiently with an 'update' operation.

Why is the transaction API inefficient? AFAICT it accomplishes the same 
thing.  Some cycles are spent on finding out nothing has changed, but 
that's fine.

-- 
error compiling committee.c: too many arguments to function