Oh, actually, this made me think of something I wanted to bring up.
What we're talking about now is basically a config file, but we
already have something called that. I was describing M5 to some folks
at work a little while ago, and there seemed to be some confusion
about how configuration worked. I think they may have assumed ahead of
time a config would be more like a static file of values (like the
ini-s used to be).
So to straighten out both of those issues, what if we called these
default and command line values the configuration, and then call the
python scripts simulation scripts? That disambiguates the term and
hopefully makes it more obvious what, say, se.py is for and how to set
up a simulation. I think it's something people usually figure out
relatively quickly, but it wouldn't hurt to make it a little more
obvious.
Gabe
Quoting Gabriel Michael Black <[email protected]>:
Three places does seem like a lot. What are they specifically?
Hopefully we can get rid of one or two.
That said, using python to generate python to put in a hidden
directory to read with python embedded in a binary is, in my
opinion, WAY more complicated than the problem warrants. The
generating script would have to be fairly smart too so you could
quickly update particular fields, remove previously set defaults, etc.
How about a file with key value pairs separated by equals signs.
Those would be used as the defaults when the options were set up,
and that would be the whole deal. If somethings doesn't make sense
as an option to the m5 binary, it wouldn't go in that file.
There are a couple of things that follow from that. First, m5path
would become an option to the binary which seems like a reasonable
thing to do in its own right. That would mean we could eliminate the
M5_PATH environment variable entirely, or leave it in somehow for
compatibility.
Second, there would potentially be a significant increase in the
number of options the binary supports which could make --help less
useful. We could define two levels of help, regular and verbose,
like hg does I think.
If we wanted to get fancy we could treat our file like hgrc and have
one version in the repo, one in the home directory, and one system
wide. Then they'd have to accumulate for paths and whatnot, I suppose.
Gabe
Quoting Ali Saidi <[email protected]>:
We could create a script and put it in the m5 root that emmitted
python files into .m5 that properly setup the environment based on
the user input. I rather like that idea and that way it could ask
where various things were and we aren't setting a bunch of
environment variables. I'm not a huge fan of the config.ini files
because pretty much every thing we're going to want to add you need
to add and check in three places. It would be better if it was just
python that setup SysPaths and whatever else correctly.
Ali
_______________________________________________
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
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
