Hi David, I'm not opposed as such, but I'd be very keen to see how invasive it is with respect to the port and bus. Perhaps an "RFC" patch on the RB?
When it comes to your question concerning the Bridge and the pointers, I would argue that a better solution is to create a RootComplex (or similar) class with a memory-facing master/slave pair, and a PCI-facing master/slave pair. Does that sound reasonable? Andreas On 17/07/2013 15:42, "David Miller" <[email protected]> wrote: >Hi Andreas, > >On 16/07/2013 23:30, Andreas Hansson wrote: >> 1) Cycles become a headache and essentially you end up building a >>spanning >> tree by keeping track of what port has already sent something, iterate >>etc >> 2) As a results of 1 you end up having a restricted set of possible >>system >> topologies even though the actual address ranges only belong to a single >> slave port >> 3) It is a complete mystery at specification time what address ranges >> correspond to what port (I'd prefer if we could even overlay the ranges >>on >> the edges in config.dot.pdf which requires it to be known in the python >> world, and currently it mostly is) > >The thing that bothers me is that PCI is, in principle, dynamically >allocated and although I agree that in simple architectures, there won't >be much reallocation, when you start introducing multiple PCI bridges >between endpoints and the CPU, managing address ranges gets to be a >headache (not least because if you add an extra peripheral, it can >potentially get inserted between two other addresses). > >You're probably right: turning this functionality on might restrict >topologies, but that might not be a problem depending on what the >specific user is doing (and provided it's an optional behaviour, not >enabled by default). > >> I'm not against re-adding some cleverness, but I'd prefer it to be very >> explicit (avoid as much magic as possible). > >Right. The changes I'm working on only get turned on if the user >explicitly specifies they want forwarding behaviour in the architecture >description file. > >If you're happy about this, can you (or anybody else) give me some clues >as to how to go about passing a C++ reference from one BridgeSlavePort >to another, driven by Python connections? > >Thanks, > >David. >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
