On Tue, Oct 26, 2010 at 5:35 PM, Avi Kivity <a...@redhat.com> wrote: > On 10/26/2010 07:27 PM, Anthony Liguori wrote: >>> >>> Sorry, I don't follow your meaning. >>> >>> When I said "size is implied" I meant that the IOPort object has a >>> separate function pointer for sizes 1, 2, and 4, so it ioport_register() >>> doesn't need a size parameter. But I don't see how that relates to your >>> comment. >> >> >> Yeah, I don't think it makes sense to combine "this is how to dispatch >> I/O" with "this is a region of I/O address space". > > Oh, so Blue meant the size of the region in ports, not the size of the > individual ports. I think that putting the range length (but not base > address) in the IOPort structure may make sense.
Yes, that's what I meant. Consider for example the handlers: they expect that the port is within some range. >> >> I think an IORegion should contain an IOPort structure though. I think >> the name needs rethinking. >> >> Maybe: >> >> struct PortIOHandler; >> struct MemoryIOHandler; > > Why two types? I think some devices use PIO on a PC and MMIO on other > architectures. Sharing the type would allow sharing code. Then there are the functions provided by rwhandler.c. I think that interface makes even more sense compared to 8/16/32 (and 64?) bit handlers in many cases. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
