I'm not running on a lot of sleep, so sorry in advance if this email
is less coherent than normal.
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.
Changing configs to m5configs seems a little redundant to me. What
would we be distinguishing it from?
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.
That, to me, suggests it's good to have some canned, gently
parameterized configurations that are not implemented directly in the
main script.
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.
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.
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?
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.
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.
Gabe
Quoting nathan binkert <[email protected]>:
Ok, so the current configs dir is a mess. I wanted to use it to try
to create an example for my batch scripts, but as it is, the code is
pretty messy, so I'd like to start a conversation about where we'd
like to take the config stuff. I think the following are some goals:
1) Turn the configurations into a package
2) Move as much code as possible out of the various example files
3) Support the python -m command line option in M5. (and perhaps use
the runpy module to do stuff in main.py) (Support -c as well?)
4) Move the examples stuff into the configs package and expect that -m
will be used for examples (m5 -d -m configs.examples.se <options>)
5) get rid of addToPath usage
Suggested steps:
Move configs/common/* into configs/
Create empty configs/__init__.py
Create empty configs/examples/__init__.py
Move common/Options.py into configs/examples/Options.py
Fix up imports.
Should we rename configs to m5config?
Comments? One question is, what do we do with the boot dir? I think
we should just leave it. There's no prohibition against having data
files in python packages.
Nate
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
