On 02/23/11 06:05, Ali Saidi wrote: > On Feb 22, 2011, at 9:52 PM, Gabriel Michael Black wrote: >> So basically what I'm worried about is creating a new, m5 only rats nest >> perhaps like those rc files you have to deal with. If we allow multiple >> files that cascade we have that problem, but if we don't then it's harder to >> have per machine settings that reflect the local file system layout, for >> instance. If we have per machine settings at all, they might cause >> unanticipated problems because they change things your batch job or whatever >> wasn't expecting. > I don't think we should have multiple files cascade. Just one in the scripts > directory with some defaults and another possible one in your home directory. > We certainly don't want a rats nest, but I think the fear of over-engineering > a system shouldn't prevent us from creating one in the first place.
Even with just those two, does the one in the source get committed? What if you don't have control over your "home" directory because m5 is being run as a different user in a batch system, or you have a minimal home directory there that's hard or impossible to get at? Then you can't use your defaults, and things get complicated. > >> As far as your .vimrc example, I think you have a point. That's an example >> of where this sort of thing is useful. The problem I see with that, though, >> is that we already have a programmable configuration system in the form of >> the simulation scripts. This is just for the little stuff you'd configure >> through the main binary which is much more limited than all the stuff you >> can control with a .vimrc. > If I continue with the .vimrc example, additionally, there can be complex > scripts that vim can include that add various features. I've got four of them > running at the moment. Yeah, but this isn't the place to add that sort of functionality. Again, this is just for setting defaults for command line options, not for extending the functionality of the simulator. If you want to do that, either adding actual code or the simulation scripts are a lot more appropriate place. You're -supposed- to replace the scripts with something that does just what you want, so customizing and extending it should be trivially available. >> What makes your command line so long? Is it options for the binary itself, >> or for the simulation script? This sort of thing won't help for the later, >> at least not without making it a bit of a hack. The only thing that makes my >> command line long as far as the binary section are any traceflags I'm >> turning on, and I doubt you'd want to force those on all the time. You're >> usage may be very different, of course. > Mostly the simulation script, but it would almost certainly change to the > binary if I was adding > --system-path=/very/long/path/to/where/i/keep/system/files > --binaries=/very/long/path/to/where/i/keep/binaries - etc. I think we probably want to keep the environment variable around so this shouldn't be an issue. It's really no harder to put M5_PATH="blah:blah" at the start of the command line than to add a command line parameter, and you could put it in your environment once and leave it there if you wanted. It's what people are used to using to specify where files are. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
