Since I think Nate is occupied right now, I grepped for .m5 and found what I think you're talking about in src/python/m5/coinfig.py. It looks like it's basically a folder you can put in your home directory where M5 will automatically look for config files. We could roll that into this too, actually.
Gabe On 02/21/11 14:56, Ali Saidi wrote: > Nate, > > Didn't you create a .m5 config file to do some of this at one point? > > Ali > > On Feb 21, 2011, at 4:40 PM, Gabe Black wrote: > >> As far as actual changes to the way paths are resolved, I was thinking >> the following. >> >> Right now, the directories in M5_PATH (or the defaults) are walked >> through one at a time, and if one exists it becomes system.dir. When the >> path for a disk image, etc., is needed, it's formed by taking that path, >> appending 'disks' or 'binaries' or 'boot' to it, and then the file name. >> >> What I'd like to do is make M5_PATH searched each time to find if a >> particular file exists, not just the directory. Also, I want to have a >> list of sub paths that extend M5_PATH. The sub paths would be tried one >> at a time by appending them to the entries in M5_PATH one at a time, >> stopping at the first match. The sub paths would be configured, using a >> utility function, to look in the right directories in the right order >> for ISA specific, variant specific, and ISA/variant specific files. >> >> So for instance, if you were to specify 32 bit linux on x86 as the >> variant and ISA, the sub paths might be 'x86/linux32', 'x86', 'linux32'. >> If M5_PATH was '/home/gblack/:/dist/m5/', the path search order would be: >> >> /home/gblack/x86/linux32 >> /dist/m5/x86/linux32 >> /home/gblack/x86 >> /dist/m5/x86 >> /home/gblack/linux32 >> /dist/m5/linux32 >> >> The ordering is designed so that the ordering of sub paths is stronger, >> ie if a file exists in x86/linux32 anywhere, it always takes precedence >> over something in just x86. That's because placement in the subpaths is >> assumed to be functionally meaningful and necessary. Then M5_PATH is >> considered so you can have files in different places. If a school, for >> instance, put a bunch of disk images or kernels or whatever in a shared >> directory, a student could use that and then also have their own >> collection of stuff to overlay it. >> >> The reason I like sub paths instead of having a fixed set of >> subdirectories to look in is that the underlying system is more flexible >> if we decide later to change some of the higher level semantics. If, for >> instance, we decided to go with linux and 32 instead of linux32, then >> we'd just have to change the sub path list. We could even do that on a >> case by case basis in the consuming scripts. >> >> One other thing to mention is that I do like having a "binaries", >> "system", etc. directory for the different types of files. Those need to >> be folded in someplace, likely between the path and sub path. >> >> Let me know what you guys think. This would all be part of a second pass >> once I do the clean up I mentioned in my earlier email. >> >> Gabe >> >> On 02/21/11 03:36, Gabe Black wrote: >>> Hi folks. I said a while ago I intended to change how various files >>> needed by M5 were located, and this weekend I started looking into >>> actually doing that. The first thing I think I'm going to do is keep the >>> end behavior basically the same but adjust how SysPaths.py works to make >>> it more amenable to the what I want to do and to clean it up a bit. >>> Looking at what it does now, there are two paths that are used if the >>> M5_PATH environment variable isn't set, "/dist/m5/system" and >>> "/n/poolfs/z/dist/m5/system". >>> >>> The later of these is obviously to make running things on the cluster at >>> UM easier, and isn't useful to anyone not in a position to do that (or >>> even some of us who are). I propose we eliminate that path outright and >>> adjust any scripts that, for instance, run the regressions to set >>> M5_PATH explicitly. >>> >>> The former path I'm less sure about. We've always had stuff in /dist >>> since I've been involved with M5 and I've always just taken it for >>> granted, but where did that actually come from? Why do we put things >>> there? I've started digging around various interpretations of what a >>> Linux file system should look like trying to find a more standard >>> location, but I haven't found anything that's obviously the right place. >>> I've seen no mention of /dist, though, so it seems even more odd now. Is >>> /dist something we could reasonably expect people to already have or to >>> not be too put out to create? Or do we want to pick somewhere less unusual? >>> >>> Gabe >>> _______________________________________________ >>> 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 _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
