Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

[Avi Kivity <avi@redhat.com>]

On 09/04/2011 06:19 PM, Anthony Liguori wrote:
>>> Yes, and the memory API is complicated and invasive :-) But it's worth
>>> it at the end of the day (although I think it could be simplified at
>>> the expensive of not allowing as much flattening).
>>
>> (we should have spent a few hours at kf2011 to convince you that this is
>> impossible)
>
>
> I don't mean for RAM, but for device I/O.

It's impossible to make the distinction.  A piece of RAM can overlay an 
mmio region and split it in two, or an mmio region can split a RAM 
region.  This means the machinery cannot consider the region type anyway.

>
> Instead of implementing it_shift in the core API, you could implement 
> it_shift by having a device that takes an input MemoryRegion and an 
> output MemoryRegion and implements the it_shift logic.

We could, but that imposes a burden on users to find that device and 
glue it to the memory API.  I'm not after a mean and lean API, I'm after 
something that is easy enough to use that people manage to get device 
models that work.

>
> I think endianness could also be handled this way too.

On some archs, endianness can find itself in RAM, so we need complete 
control.  And again, I don't want users gluing stuff together the wrong 
way, I want them using a simple interface.

-- 
error compiling committee.c: too many arguments to function