Interesting idea... a few quick thoughts: - 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?
- 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. - 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. - 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. - 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. Steve On Wed, Apr 7, 2010 at 2:55 PM, nathan binkert <[email protected]> wrote: >> Could you sketch out what the code would look like to do this? > Something like this: > > struct InfoMessage > { > virtual ~InfoMessage() {} > }; > > class Port > { > bool sendInfoMessage(InfoMessage *ir) { return peer->recvInfoMessage(ir); } > virtual bool recvInfoMessage(InfoMessage *ir) = 0; > }; > > struct BlockSizeRequest : public InfoMessage > { > int blockSize; > }; > > struct AddressRangesRequest : public InfoMessage > { > AddrRangeList ranges; > bool snoop; > }; > > class MyPort : public Port > { > bool > recvInfoMessage(InfoMessage *ir) > { > BlockSizeRequest *bsr = dynamic_cast<BlockSizeRequest *>(ir); > if (bsr) { > bsr->blockSize = blockSize; > return true; > } > > AddressRangeRequest *arr = dynamic_cast<AddressRangesRequest *>(ir); > if (arr) { > arr->ranges = foo; > arr->snoop = false; > return true; > } > > return false; > } > }; > >>> It seems to me that the printAddr mechanism that Steve did could also >>> be folded into this mechanism as well (instead of hijacking >>> sendFunctional). Maybe this one is going too far, but for the other >>> ones, I don't see a good reason not to do this. >> >> Seems like that might be too far. >> >>> One thing that is interesting no matter what we choose is what to do >>> when an object doesn't know about an information request type. Should >>> we just pass the request through the object (and broadcast it in the >>> case of networks/busses), or should we error out? >> >> I would imagine it should pass it on, maybe printing a warning? >> >> Ali > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
