Hi Jason, Thanks for your reply, it should be an adequate solution, even if it looks kind of awkward to me right now ;) While I wanted the downstream controller (B) to have a reference to the upstream (proxied) controller (A), I must actually do the opposite and have (A) store a reference to (B). Then, (A).init() will call (B).registerUpstream(this). It does not feel natural to set this "(B) references (A)" relationship in (A)'s python parameters but it is required not tho create a cycle in the hierarchy.
Looking at it again, it looks like, for instance, a RubyController references a RubySystem that references the System in turn. So the inclusion relationship in python parameters is the opposite of the architectural inclusion relationship, if I can say so. In other words, if C++ class (B) needs a reference to C++ class (A), Python class (A) will typically hold a reference to Python class (B) and (A).init() will call (B).registerA(this). Is there a reason for adopting that design? My guess is that it allows to build the system top to bottom in the python scripts. Cheers, Gabriel _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
