On 2011-05-18 19:15, Avi Kivity wrote: > On 05/18/2011 08:07 PM, Jan Kiszka wrote: >> On 2011-05-18 18:47, Avi Kivity wrote: >>>>>> I'm specifically thinking of fully trackable slot updates. The clients >>>>>> should not have to maintain the flat layout. They should just receive >>>>>> updates in the form of slot X added/modified/removed. For now, this >>>>>> magic happens multiple times in the clients, and that is very bad. >>>>> >>>>> Slots don't have any meaning. You can have a RAM region which is >>>>> overlaid by a smaller mmio region -> the RAM slot is split into two. >>>>> >>>>> We should just send clients a list of ranges, and they can associate >>>>> them with slots themselves. >>>> >>>> And that association logic should be as simple as matching a unique >>>> range ID against an existing slot (for updates and deletions) or adding >>>> a new slot for a new range and storing the ID. Anything else will not >>>> allow to simplify the existing code bases noticeably. That's my point. >>> >>> We won't have a natural ID. >> >> The address of the data structure describing a region could be such a >> thing. Provided, of course, we prepare a flatted view ahead of time, not >> on the fly. > > It will change as soon as the memory map changes.
...which is supposed to be properly reported to the client beforehand. > >>> But I'll see if I can have a library >>> calculate the minimum difference between the previous layout and current >>> layout. Should not be too hard. >> >> We need exact match on the client side with the old range. E.g. if you >> put a new region over an existing one, effectively splitting it into two >> halves, the core has to >> - shrink the existing range to form the first half >> - register two new ranges to reflect the rest >> >> On unregistering of that overlap, we need the reverse. So all the client >> has to do then is to decide if it is interested in some range, and then >> store it internally with some additional data (and process it, of >> course). No more merging, no more overlap detection and splitting up at >> client level. > > Right. We do a symmetric set difference between the old and new maps > and let the client know what has changed. That would be fine as well. Then the internal representation could be anything, though I bet a flattened form would have its advantages. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
