Re: [PATCH] memory: transaction API

Avi Kivity
2011-07-21T12:13:21Z

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