Hi Gabriel, I agree it's not intuitive and it's a bit awkward.
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. > Haha! No, there's not an underlying reason for this. In fact, I would guess that there is a much better design which wouldn't require this awkward pattern. As an aside, I was recently re-writing some Ruby config scripts and got bitten by these circular dependencies as they require you to construct your system in a very strange way. Cheers, Jason On Wed, Apr 14, 2021 at 1:36 AM gabriel.busnot--- via gem5-users < gem5-users@gem5.org> wrote: > 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 >
_______________________________________________ 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
