>
> Ah:
>
> - /* If we see a hole, break the region. */
> + /* If we see a new offset, break the region. */
>
>
> But, sorry for being slow, I don't see why it requires a core update
> (other for adding mrp->offset).
So far we matched accesses in find_portio by considering the portio
offset as well. If we want to replace the region offset with the portio
one (which confines legacy to a legacy-only place), we need to make the
portio offset a pure correction value on handler invocation and exclude
it from any range matching. And that means an old_portio memory region
can only describe one range starting exactly at MemoryRegion::addr.
>
>>
>> > They all use the same handler, so you need to split e.g.
>> > sh7750_io_memory into six MemoryRegionsOps. Or use tricks with
>> aliases -
>> > have one giant 4G region with one handler, and map six 4k aliases into
>> > the system address space.
>>
>> Looks more like 3 regions with one alias each. But we likely need to
>> disentangle all that logic first. I would be surprised if there wasn't a
>> more readable way to express it via the memory API.
>>
>
> Depends if you subscribe to the "blindly make it work exactly the same
> way" or "understand the details and rewrite it cleanly" brands of
> masochism.
We generally used to convert from APIv<n-1> to APIv<n> by adding legacy
wrappers, rarely removing any of them. This doesn't scale, but - granted
- it requires some masochism to make progress.