...and as you will see in the latest edition of the patch (http://reviews.m5sim.org/r/942/) it is now reduced to adding the port in the System along with a "getter".
Thanks for all the input, I'm glad we could strip it down to what was really needed. Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Andreas Hansson Sent: 06 January 2012 13:30 To: gem5 Developer List Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point I am actually in the process of seeing it the systemPort introduction can be done relying entirely on the existing system parameter in Process etc, and I think it might just work. In other words, the only objects that need to get a pointer to the port has the system as a parameter. I'll get back to you with an outcome within an hour or two. Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: 06 January 2012 13:27 To: gem5 Developer List Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point On Fri, Jan 6, 2012 at 1:30 AM, Gabe Black <[email protected]> wrote: > On 01/05/12 12:28, Steve Reinhardt wrote: > > > > So I think we're agreed on the hierarchy, and are down to three general > > naming conventions: > > > > 1. SimObject > PortedObject > SysObject > > 2. SimObject > PortedObject > MemObject > > 3. SimObject > MemObject > SysObject > > > > with minor variants where we substitute other new names for PortedObject > or > > SysObject (though those are my current favorites). > > > > #2 keeps existing children of MemObject as MemObject, but changes what > > MemObject is. > > #3 keeps the MemObject class itself unchanged, but requires reparenting > > current MemObjects to SysObject. > > > > In any case, objects that want to enjoy the inherited System param but > > don't need ports get stuck inheriting the port code anyway. I don't > have a > > problem with this. In case #2, those objects also end up being derived > > from MemObject, which seems odd since they're not in the memory system. > > Case #3 has a similar problem in that SysObject derives from MemObject > > even though not all SysObjects are in the memory system; somehow that's > > less objectionable to me because it only happens once. > > > > So maybe after all this I've talked myself into option #1... > > > > A fourth approach that comes to mind is to go with #2 above, but *not* > have > > other non-memory objects that want a System parameter derive from > > MemObject. Instead, as a separate task, we could add a SysObject that > > derives directly from SimObject but has the System param, and the objects > > that need the param but not ports could derive from that. It's not > elegant > > (I think I still prefer #1) but I could live with this. > > > > Sorry for the length here... mostly just thinking through this myself as > I > > type. > > > > Steve > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > I think there weren't very many places where the system pointer was > actually used, so making a whole class to avoid adding system parameters > where necessary seems like overkill. Sounds like an argument for my option #4 (which is really a variant of #2). I'm OK with that. > There may be more instances than > I'm thinking, but maybe they all already share a common ancestor like > the Platform class. As I said above, there's IntrControl and SimpleDisk that have system params and aren't derived from Platform. The only other case I can find is Process, which is sort of interesting in that it's not really a "system component" in the hardware sense. Certainly if we go with option #4 then a small improvement would be to put factor the system param out from all the Platform-derived objects into Platform itself. > Is it so they can check the memory system mode? Do > we really need that to be attached to the system object since it's > really global across the simulation? Memory mode is not global across the simulation. In a multi-system simulation it's perfectly OK to have one system in timing mode and the other in atomic. Steve _______________________________________________ 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 -- 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
