This should be completely backwards compatible, even with noncoforming names. The new version of the default getPort won't be able to handle them, but it will just complain and then ignore them. You can always override getPort yourself and handle any names you don't want to pass down to the default implementation. Since the default used to just be to print an error and die, nobody should be depending on it doing anything non-fatal.
With the change Andreas is suggesting (absorbing the name() + ".foo" into the Port constructor), then the semantics of things would change and you'd have to update. I'm generally in favor of that change, but since it breaks compatibility I'd want to treat it separately. Also, MemObjects are historical baggage now and don't do anything other than provide backwards compatibility. The only thing they used to do was host the getPort function, but now that that belongs to SimObject the MemObject doesn't really need to exist. Gabe On Tue, Sep 3, 2019 at 4:39 PM Jason Lowe-Power <[email protected]> wrote: > Hi Gabe, > > I like the idea of this change. Getting rid of that silly getPort > boilerplate is really nice! > > I've looked through the changes, but maybe because it's late in the day, I > can't figure out how backwards compatible this change is. If I have my own > MemObject that's not in the mainline, will I need to make changes or will > everything "just work" (assuming I don't have non-conforming names)? If > it's *not* backwards compatible, then I suggest keeping the old interface > as well, if possible. > > Cheers, > Jason > > On Tue, Sep 3, 2019 at 2:33 AM Gabe Black <[email protected]> wrote: > > > Another reason I'm treating the getPort part of things as an RFC is that > it > > is nice to have the flexibility of getPort, and I don't want to try to > > envision every possible way getPort could useful be used and make a > > dodad which will provide that specific functionality. For instance, I > could > > make something that would know how to forward ports in C++, or allow port > > aliases, but would that be any easier to use than just writing a little > > function to do it on the spot? Not having to do that in most simple cases > > is nice, being able to do it is nice, but having a hodge podge of doing > it > > manually and not is a little off putting... > > > > Gabe > > > > On Tue, Sep 3, 2019 at 2:26 AM Gabe Black <[email protected]> wrote: > > > > > Hi folks. I was looking at creating a base Interrupts class which would > > be > > > ISA agnostic, and noticed that the x86 version inherited from > > > BasicPioDevice. If I wanted to maintain its functionality, I would need > > to > > > either make the base Interrupts class also inherit from BasicPioDevice, > > or > > > to reimplement that functionality directly in the x86 Interrupts > object. > > > > > > That didn't seem great. I thought about it a bit, and as a first step > > > decided to try templatizing PioPort so that it would be easier to use > > > without a PioDevice to go with it, complicating the inheritance > > hierarchy. > > > > > > https://gem5-review.googlesource.com/c/public/gem5/+/20568 > > > > > > That worked out well, but then I noticed that I'd have to write some > > goopy > > > boilerplate code to make the port work which BasicPioDevice took care > of. > > > It occurred to me that it would be possible to make ports register > > > themselves with a SimObject and then have the SimObject know to return > > them > > > in a default getPort implementation. That way the object hosting them > > > wouldn't have to do much more than just instantiate them with > parameters > > it > > > already needed to give them (more or less), and it would take care of > > > itself. > > > > > > That seems to also have mostly worked, although it touches a lot of > files > > > and I've only had time to do some very minimal testing (x86 hello world > > and > > > initial Linux boot). There are some places where getPort was doing > > > something more than the most basic, and those were left alone. > > > > > > https://gem5-review.googlesource.com/c/public/gem5/+/20572/1 > > > > > > One nice side effect of this effort is that it identified places where > > > ports were named using an inconsistent scheme (name() + "-foo" or just > > > "foo" instead of name() + ".foo"), or were not named the same thing in > > > python as they were in C++. > > > > > > Since this is a large change that only partially eliminates getPort, I > > > thought I'd treat this as an RFC for now and see what people think. > > > > > > A couple things I'm thinking of to improve the implementation is to > make > > > the PortNameMap more of a separate class than a map and a collection of > > > functions. That will make it easier to use in other places like in > > systemc > > > objects which have a parallel but independent mechanism in C++. > > > > > > I'm also thinking of setting up a Port forwarding mechanism in python > > > where you could say something like: > > > > > > class Foo(SimObject): > > > port = ForwardPort(other_object's_port) > > > > > > And then when binding happened, it would go grab that other port from > the > > > other object and not try to get it from Foo. That won't help when ports > > are > > > forwarded to internal C++ objects which actually own the ports, but it > > > would help if, for instance, you wanted to create a SubSystem which > > wrapped > > > some objects and wanted to poke some of the internal ports out for > people > > > to connect to. > > > > > > I'm also thinking about making some sort of container for vector ports > > > which would also take care of registering with the SimObject so you > don't > > > have those clunky explicit addVectorPort calls lying around. > > > > > > Gabe > > > > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
