Am 09.06.2011 um 17:03 schrieb Markus Armbruster:
Andreas Färber <andreas.faer...@web.de> writes:
Signed-off-by: Andreas Färber <andreas.faer...@web.de>
---
hw/isa-bus.c | 14 ++++++++++++++
hw/isa.h | 1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index d258932..1f64673 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -105,6 +105,20 @@ void isa_init_ioport(ISADevice *dev, uint16_t
ioport)
isa_init_ioport_range(dev, ioport, 1);
}
+void isa_discard_ioport_range(ISADevice *dev, uint16_t start,
uint16_t length)
+{
+ int i, j;
+ for (i = 0; i < dev->nioports; i++) {
+ if (dev->ioports[i] == start) {
+ for (j = 0; j < dev->nioports - i; j++) {
+ dev->ioports[i + j] = dev->ioports[i + length + j];
+ }
+ dev->nioports -= length;
+ break;
+ }
+ }
+}
+
"discard"? It's the opposite of isa_init_ioport_range(), name should
make that obvious. "uninit"?
"uninit" felt wrong.
Note: this only affects the I/O-port bookkeeping within ISADevice, not
the actual I/O port handler registration. Any use must be accompanied
by a matching handler de-registration. Just like any use of
isa_init_ioport_range() must be accompanied by matching
register_ioport_FOO()s. You can thank Gleb for this mess.
Right, I didn't spot any wrong usage though.
So what about cleaning up the mess and doing
isa_[un]assign_ioport_range(), wrapping the ioport.c functions?
The overhead of calling it up to six times for the different widths
and read/write would seem negligible as a startup cost. And for
pc87312 we don't seriously have to care about performance imo.
Andreas