> I was actually thinking about this the other day I think because of the > SMARTS config changes. My suggestion would be to build up composite > primitives that can be wrapped up in thin, simple, flexible scripts to get > common configurations. I think we really need to set up stronger, more > opaque, better defined boundaries between the different pieces of the > configuration package, and move things to where they make sense to be > logically. All of this is handwavy, of course, but I think it's important to > get away from the model, intentional or otherwise, of hacking up the example > se.py. I think we need to either make se.py a real thing where it's an > official interface to M5 (as it's actually being used today), or deflate it > until people will basically be starting from scratch when they reuse it. The > pieces are also all too tied to each other to be able to change things too > much without some significant effort. This all sounds reasonable. My goal is to eventually merge the stuff in tests/configs and configs/. That said, I don't need revolution at this point. Just cleaning up what we have would be better than the status quo.
> Changing configs to m5configs seems a little redundant to me. What would we > be distinguishing it from? If we turn it into a regular package, the worry is that configs is too generic a name and could conflict with other stuff when importing. > To step back a little, how do we imagine people are going to use the config > stuff? I'd imagine people will probably want to be able to put together a > sane, architypical configuration really quickly without a lot of code, get > at the --whatever options they're used to that allow them to control > important parameters like the actual executable easily without having to > reimplement them, and then they're going to want to be able to add their > twist, whatever that might be, without having to redo everything from > scratch. Yes. > That, to me, suggests it's good to have some canned, gently parameterized > configurations that are not implemented directly in the main script. If you mean move stuff from se.py to configs/common, then I agree. > It would be great, I think, if we had a blob of prepackaged --whatever > options for the various scenarios that make sense. Then they can be defined > in a common way, and either the various components of the system know where > to look because the options are well known (or have some options.getVal > thing for the option modules?) or they're just stubs and need to be plugged > into the (hopefully clearly marked, in a philisophical sense) consuming > objects. Don't we sort of have that with common/Options.py? > Modularization and appropriate parameterization is key. If I want to put my > twist in there by, say, replacing all L1s with my superL1 object, I > shouldn't have to change any (or at least minimal) canonical library code, > nor should I need to copy and paste large chunks of it to change one or two > things. You can't parameterize everything, but more is likely better than > less. The whole config system was designed around this goal. It is difficult to achieve though and I don't think we've exactly figured it out yet. This is a lofty goal, and a bit beyond the changes I'm proposing now. > Finally, this hypothetical person will probably want to put their scripts > someplace, and if there's no obvious alternative I think they'll just end up > wedged in the configs directory as examples/myse.py for instance. Maybe we > should have a directory specifically for the highest level scripts that are > either written by users or do very little to wrap other functionality? Users can write their own script directory and import m5config if they want to get any of the default m5 stuff. That not reasonable? > Also, how strong is the name "common"? Is that "common" as in "this shows up > every now and then" or "common" in "this is common to all scripts"? I don't > know if it's a problem or not, but we should pick a strenght and stick to > it, and things that don't really fit should go somewhere else. Stuff that's > occasionally useful and can be pulled in when needed shouldn't get in the > way of truely universal stuff. I want to get rid of common and just put it directly under configs (which I'd like to rename to m5config) > Would using -m and -c add additional required knowledge for someone using > M5? I had to look up what they do. If they don't make anything fundementally > cleaner or more capable they seem like unnecessary complication to me. Like > I said, though, I had to look them up so I'm sure I'm missing their subtle > nuances. -m is pretty trivial. It just says, look for a package and execute the specified module within that package. It would mean a simple user command line and it would also mean that we wouldn't have to do any of that addToPath stuff (except maybe for tests so that it could find the m5config package). Alternatively, we could compile m5config as m5.config directly into M5 proper. Not sure if that is a good idea or not. The downside is that by default changes to m5.config would require a recompile (though I've got a new option that makes that unnecessary during the development phase). The upside is that everything is in the same place and imports are trivial. -c would just be for completeness. It would also make it easier for me to debug python changes. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
