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.
> 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. > 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. Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
