I don't want to beat the issue to death (too late?), but I think
you'll agree that as implemented this is a hack. A sometimes useful
hack that hasn't caused any serious problems so far, but still a hack.
I'd like us to get rid of hacks by getting rid of the code or turning
them into non-hack features. In this case, turning it into a feature
would add a lot of code and complexity for not a lot of extra
functionality (which I think you've said as well), so I'd prefer it
got axed. Then again I didn't even know the code was there until Ali
brought it up and I actively looked for it, so it's more a
philosophical question whether to keep it or not (vs. expanding it
which is a different sort of issue). If it helps you and it doesn't
hurt anybody then I wouldn't mind leaving it alone.
Gabe
Quoting nathan binkert <[email protected]>:
Ok, there's this long thread on how to deal with default configuration
options which turned into a specific argument about M5_PATH=
So, what's the deal? I created a mechanism for having an m5
configuration directory ($HOME/.m5, but can be overridden by the
M5_CONFIG environment variable) and specifically an options.py file in
that config directory. options.py gets executed before main() with
one parameter in the global dict, the options dictionary. This
options dictionary can be modified to change default values of m5
options (the things that go before the script name), or even add
options that are specific to an installation. Examples of things that
are convenient to do in such a file: change the default output
directory, change the default statistics output file name, change the
defaults for stdout and stderr (and redirecting those outputs), making
the output quiet, changing the default port of the remote debugger,
and set the script path.
All of these things have been pretty convenient for me at times. You
can even parse command line options to add your own in here (though
that can be a bit of voodoo), and do things like enable iron python if
you ever use the interactive python prompt, or do things with pdb if
you use pdb.
What I wrote above is now the extent of the documentation of this
feature. The thought was that the files in this directory could
basically be used like hooks are used in mercurial.
Now it's true that few (one?) people ever use this, and a lot of
people end up writing wrapper scripts for m5 command line stuff, e.g.
if you're running in a batch system. That's of course possible, but
it begs the question, if you're going to write a bash script to wrap
M5, wouldn't it be better to write a python script that more or less
has access to all of M5 (and requires less code at the same time?). I
agree that it is more or less impossible to document this feature
fully, but it may be easy enough to document the few things that
people actually want to use.
I'll totally agree that the way it is implemented may be poor, and we
may want to have a single configuration file with specific entry
points (a .m5.py file that exports a set of functions that get called
explicitly like hooks), but that's not hugely different. Requiring me
to write wrapper scripts for M5 is annoying though.
There is one totally different way to approach this of that we (or
specific users that care) can stop using the m5 "binary" and start
using libm5.so. Did you guys know that you can build m5 completely as
a library and do "import m5"? That would then make it obvious that a
script can choose whether or not to call M5's main() routine.
No matter how we do it, I still like the ability to control what's
happening in M5 way early in execution. Even if it is a mostly
undocumented feature for m5 hackers like me, it has made it easier for
me to implement and do stuff and it's easy enough to document the few
things that people might want to do. Anything else (environment vars,
ini files, etc.) is actually more code and more maintenance.
Nate
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
