On Monday, September 26, 2011, nathan binkert wrote:
> > I'd still lean
> > toward getting rid of m5.internal.params, but that might maintain
> backward
> > compatibility with those older versions of swig.
> The real issue with the older version of swig was that you couldn't
> get the C++ module (remember that with swig, there's a "foo" python
> package and a "_foo" c++ package) to be within a package, so I
> prepended the params_ to the name so that there'd be no collisions
> between our C++ packages and existing packages. Make sense? I think
> that the only way to get rid of this is to use the package= option to
> %module and advance to 1.3.39. Did you decide that you wanted to do
> that?
>
I'm confused... we're already using the package= option, I just made changes
like this:
- code('%module(package="m5.internal") param_$cls')
+ code('%module(package="m5.internal.swig") $cls')
What effect did that have in the older broken versions?
>
> > I guess my main motivation for getting rid of m5.internal.params is that
> it
> > seemed confusing and unnecessary, and I think this patch shows that it's
> > unnecessary, so I'd still like to get rid of it. I'm just not completely
> > confident that what I've replaced it with is the best solution.
> > Thoughts?
> I'm not sure why it's so confusing, and I'm ambivalent about getting
> rid of it.
I think there were two main things that confused me:
- the name 'params' isn't that descriptive, since the wrappers for the C++
SimObjects end up in there as well as the generated FooParam structs and the
other misc. param class definitions
- the process of programmatically importing things based on a partial string
match of identifier names from a different package is just sketchy... it's
understandable as a bug workaround, but doesn't seem like a long-term
solution, particularly when the reasons behind it aren't documented :-)
> Would you be happier with s/internal/generated/ ?
>
Perhaps... that crossed my mind. Or s/internal/swig/. The problem with
"generated" is that, as I mentioned above, we have things that are generated
three levels deep (python generated from .i files generated from C++ structs
generated from python) so "generated" is kind of ambiguous when you're not
clear on which layer you're talking about.
> One thing that we should think about supporting some day is parameters
> within namespaces. (Well, namespaces in C++ and packages in Python).
> I'm not saying that you need to enable that now, but I'd suggest that
> you don't prevent that. If we ever get to the point where people
> start using EXTRAS a lot, namespaces will become important. (They
> would also be important if we wanted to support multiple ISAs in one
> binary).
>
Good point... seems like when we get to that point we should put most if not
all the SimObject classes in namespaces, then the related parameters will
just follow. I'm fine with leaving that to a future change though.
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
