On 2/23/11 3:49 AM, "Gabe Black" <[email protected]> wrote:
>On 02/22/11 09:33, nathan binkert wrote: >>> 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. >> This is probably right. Though I think the name = value file should >> either be python code (this is more or less how it is now since you >> just do name=value and not much else.) or a .ini (because there's an >> easy to use parser and it's a well known file format). >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev > >You know, I thought about this more, and I think we're sort of going >down a rabbit hole here. If we use a .ini file, then there's not a good >way to do things like build up an M5_PATH to have multiple components. >If we make it more python like, then we add a new avenue/dimension for >complexity, more surface area for compatibility issues, etc. Do values >that are set for the machine get taken into consideration? What happens >if you run on a cluster and somebody has a file that that screws up your >run? Do you then have to add all the options to the command line anyway >to be safe? Then you have to ask is this actually useful? In some >circumstances I think functionality like this (setting specialized >defaults) could be useful, but in the thousands of times I've invoked >M5, I've never wished I could change the defaults. Also, I think the >same effect could be had through a wrapper script, shell alias, etc. > >So in the end I think we should scrap this default changing stuff. I >think it's at least partially an example of widgetry for widgetry's sake. > >I also still like the M5_PATH environment variable. It's analogous to >PATH which people already understand and does a similar job. If there >really are a bunch of different ways of setting up the path then we >should try to consolidate them, but this seems to be the one that makes >the most sense. I certainly have. I think having a defaults.py which is pretty much just a dict: defaults = { 'path' : '/path1:/path2:path3', 'outputdir : 'm5out', 'cpu2000' : 'some/other/path', .... } If exists('~/.m5'): exec(~/.m5 And then having a .m5 file which says: defaults['path'] = 'whatever/you/want/here' Inside m5 scripts whereever something like this is required you simply import defaults and use it. In the simple case it's easy. If someone wants to get creative with their path formation they can. if os.uname()[0] in ['host1', 'host2']: Defaults['path'] = '/dist/m5' elif os.uname()[0] == 'mylaptop': Defaults['path'] = '/work/m5' else Panic("no idea where to get files") Thoughts? Ali -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
