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
