On 12/14/2011 03:53 PM, Anthony Liguori wrote: >> The fact that serial.c (which really should be called 16550.c) >> contains ISA >> specific IO callback routines feels like ISASerial isn't doing its job >> proberly to start with :-) > > > It's not really ISA specific callbacks but I need to think through > interaction with the memory API. > > In my qom-next branch, serial.c exposes a > serial_ioport_read/serial_ioport_write function. isa-serial.c and > mm-serial.c create MemoryRegions based on thin wrappers around that > callback. > > Ideally, serial.c would export a MemoryRegion directly for the > registers it supported and isa-serial.c and mm-serial.c could bridge > that to the appropriate address space. > > I think the problem here ends up being itl_shift. I think Avi's > trying to avoid having a non-flat dispatch space so you can't really > create a MemoryRegion that dispatches to another MemoryRegion.
In fact I want the ability to create new address spaces. For example index/data style interfaces, as found in RTC, IOAPIC, and PCI 0xcf8 style config space, can be hooked to drive an RTC MemoryRegion, an IOAPIC MemoryRegion, and the PCI config space address space. > We discussed it before and I believe he was planning on adding > itl_shift as a MemoryRegion mutator. I don't think it makes sense as a mutator, can it_shift change dynamically? But as part of setup, yes. > Avi, did I understand that all correctly? If you mean that the interface between serial.c and isa-serial.c (or however they're renamed) should be MemoryRegions exposed by one and mapped by the other, then yes, I think that's the right interface. -- error compiling committee.c: too many arguments to function
