> - Seems like we're conflating two different types of requests here, > things like block size which are just direct queries, and things like > address range that are recursive. Is that a good idea? Very true. I initially named the class InfoRequest, but changed it to InfoMessage since it could be a push or a pull. The mechanism is the same for push and pull in theory, perhaps we should just make sure we have Push or Pull as part of the name. I don't see any benefit of having two separate functions though.
> - How about having a non-abstract base implementation that's called on > unknown packet types? Then you can control whether requests that are > unimplemented by a particular device are ignored, generate warnings, > etc. by how they're handled in there. I thought that too. For example getBlockSize has a default return value of zero. The question is, where does the default go? It should probably go into the base class and we always do a "return Parent::recvInfoMessage(im);" at the end of every function. Alternatively, the default could go into the InfoMessage class itself, though this seems a bit odd since it's not easy to override. Be nice if we could actually use a visitor (more below). > - If we're going to revamp how the address-range stuff is done, let's > try and find an approach that doesn't involve dozens of iterations. > Not that the performance matters, but it's a pain to trace through all > those calls on the rare occasion it's necessary. One possibility > would be to use this same interface to push information to a peer > rather than just send a query to pull it. I'm not positive that > helps, but it's a thought. I think push would be nicer since that's really what we're doing under the covers. A status RangeChange invariably causes a getAddressRanges. I was going to add that to my example code, but I wanted to keep things at a high level initially. > - Are there advantages to using this for printAddr over the current > implementation? The one awkward thing I recall about printAddr is > that you need a port to inject it from (a little awkward from gdb), > but I don't see that this approach fixes that problem. Not sure. My thought was that it could go in either place and the info thing seemed to make a little bit more sense since in theory you're bloating the functional interface. I don't think it matters too much. > - Interesting that this is almost a visitor pattern, but not quite; > you don't have the virtual call on the InfoMessage argument since you > want to do things that aren't necessarily exposed as separate > functions on the MemObject. It would probably be nice to actually use a visitor, but the main problem there is that the type could get lost if you implement a policy of passing unknown messages through your object. i.e. once you cast to the base class to get the default behavior, there is no way to cast back to the derived class when you get to the next object. Be kinda nice if you could do polymorphic function overloading, but I don't think there really is any way to do such a thing without serious headaches and grossness. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
