> Since these all generate their own packages (e.g., the SystemParam object is > in the m5.internal.swig.System package), maybe it makes sense to leave them > directly in m5.internal instead of creating a subpackage... Seems fine to me. I mostly did it originally so that there wouldn't be any accidental name collisions, but perhaps that won't ever happen.
> 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 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. Would you be happier with s/internal/generated/ ? 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). Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
