MEM: Pass the ports from Python to C++ using the Swig params
Review Request #1002 - Created Jan. 17, 2012 and submitted
| Information | |
|---|---|
| Andreas Hansson | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
MEM: Pass the ports from Python to C++ using the Swig params This patch adds basic information about the ports in the parameter classes to be passed from the Python world to the corresponding C++ object. Currently, the only information passed is the number of connected peers, which for a Port is either 0 or 1, and for a VectorPort reflects the size of the VectorPort. The default port of the bus had to be renamed to avoid using the name "default" as a field in the parameter class. It is possible to extend the Swig'ed information further and add e.g. a pair with a description and size.
util/regress all passing (disregarding t1000 and eio)
Posted (Feb. 1, 2012, 5:30 a.m.)
pretty much looks fine, but Nate probably understands the swig stuff much more than I
-
configs/common/FSConfig.py (Diff revision 1) -
isn't think default_slave?
-
configs/common/FSConfig.py (Diff revision 1) -
isn't it a default slave?
-
src/python/m5/params.py (Diff revision 1) -
This return True or False, not an integer. I think that to be really correct, you should do int(self.peer != None)
Posted (Feb. 2, 2012, 1:54 a.m.)
-
configs/common/FSConfig.py (Diff revision 1) -
Yea, this is confusing... it's the bus's default master port, but the thing you hook up is the default slave device. I would prefer to leave this as 'default' and fix the keyword collision elsewhere (see below).
-
src/python/m5/params.py (Diff revision 1) -
I'm not too fond of just using the bare port name here, as there is still potential for name/keyword conflicts beyond 'default', plus it's not as meaningful a name as it could be. Why not something like 'port_${{self.name}}_connection_count'? Also, do you envision passing more than the connection count eventually? If so, it might be worth putting a struct here even if it only contains an int for now.
Looks fine to me with or without the port_ prefix. The name I gave was just a suggestion. Part of the reasoning was that this would be easy to expand into a struct later, e.g., port_${name}.connection_count. If it's simply length that's bugging you, you could also abbreviate "connection" as "conn".
Any of these options are fine, and if it turns out to be confusing we can always rename it later. Just pick one and commit it; no need to repost a diff on my account.