MEM: FunctionalPorts are replaced with PortProxys
Review Request #920 - Created Nov. 28, 2011 and discarded
| Information | |
|---|---|
| Andreas Hansson | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
| ali, gblack, nate, stever | |
MEM: FunctionalPorts are replaced with PortProxys This patch introduces the PortProxy instances replacing the FunctionalPorts. This requires small chagnes to many files. After this patch there are only structural Port objects left in the source.
util/regress passing all ignoring failing eio and t1000
Posted (Dec. 3, 2011, 1:10 a.m.)
-
src/cpu/thread_context.hh (Diff revision 1) -
I think we should call this getPhysProxy() instead to stay parallel with getVirtProxy().
-
src/cpu/thread_state.hh (Diff revision 1) -
Seems strange that this change shows up in this patch and not the VirtualPorts patch. I'm tempted to suggest that all these patches get merged anyway, in which case it won't matter.
-
src/mem/physical.cc (Diff revision 1) -
Should uncomment or remove this line, or maybe convert the panic to a warn.
-
src/mem/translating_port.cc (Diff revision 1) -
It would be nice to see this file moved to se_translating_proxy.cc and then have patches applied to it, since I believe the bulk of the code is unchanged. Same with vport.cc && fs_translating_proxy.cc, and any other pair of files where we're just renaming classes or methods but not actually generating much new code.
