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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
