The code managing DRCs[0] has quite a few things that are more
complicated than they need to be. In particular the object
representing a DRC has a bunch of method pointers, despite the fact
that there are currently no subclasses, and even if there were the
method implementations would be unlikely to differ.
This appears to be a misguided attempt to "abstract" or hide things in
a way which is bureaucraticl, rather than meaningful. We may have an
object model, but we don't have to adopt Java's kingdom-of-nouns
nonsense[1].
This series makes a start on simplifying things. There's still plenty
more, but you have to start somewhere.
[0] "Dynamic Reconfiguration Connectors" a firmware abstraction used
in hotplug operations
[1]
https://steve-yegge.blogspot.com.au/2006/03/execution-in-kingdom-of-nouns.html
David Gibson (4):
spapr: Move DRC RTAS calls into spapr_drc.c
spapr: Abolish DRC get_fdt method
spapr: Abolish DRC set_configured method
spapr: Make DRC get_index and get_type methods into plain functions
hw/ppc/spapr.c | 13 +-
hw/ppc/spapr_drc.c | 404 ++++++++++++++++++++++++++++++++++++++-------
hw/ppc/spapr_events.c | 10 +-
hw/ppc/spapr_pci.c | 4 +-
hw/ppc/spapr_rtas.c | 304 ----------------------------------
hw/ppc/trace-events | 2 -
include/hw/ppc/spapr_drc.h | 9 +-
7 files changed, 355 insertions(+), 391 deletions(-)