ndent on the implementation of these objects making these harder to chnage in
the future so a better way may be to add methods to fdc and serial to allow
changing their base address and map/unmap their ports and keep their internals
unexposed.
Each ISADevice sub class would need concenience methods as well as each state
class. This series touches three of each: fdc, parallel, serial. And each of
those need two convenience methods: set_enabled() and set_address(). This would
add another 12 functions on top of the current ones.
If all ISA devices need this then these should really be methods of ISADevice
but since that's just an empty wrapper over devices each of which handles its
own ports, the ISADevice does not know about those and since each device may
have different ports and not all of them uses portio lists for this, moving
port handling to ISADevice might be too big refactoring to do for this. Keeping
these functions with the superio component devices so their implementation is
kept private still worth it in my opinion so even if that adds 2 functions to
superio component devices (which is not all ISA devices just a limited set)
seems to be a better approach to me than breaking encapsulation of objects.
These are simple access methods for internal object state which are common in
object otiented programming.
Then ISASuperIODevice would require at least 6 more such methods (not counting
the unneeded ones for IDE which might be desirable for consistency). So in the
end we'd have at least 18 more methods. Is this really worth it?
We may do without these if we say superio is just a container of components so
don't add forwarding methods but we can call the accessor methods of component
objects from vt82c686.c. That's still better than reaching into object
internals from foreign objects.