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
