On 2011-07-21 14:58, Avi Kivity wrote: > On 07/21/2011 03:52 PM, Jan Kiszka wrote: >>> >>> 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. >> >> We do not need to provide update support for each and every bit, but for >> the common cases. memory_region_update_alias(region, offset, size) would >> be an excellent first candidate IMO. > > It's not enough, look at cirrus and PAM. It's a perfect fit for cirrus, but PAM indeed requires set_readonly in addition. I also think now that describing a memory region offline via a struct and then passing that to an atomic add/del/update would be a more handy and future-proof API than an increasing number set functions. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
