I seem to remember being able to change things like SysPaths in it, or at least how Nate intended it to work. Of course, there's no documentation about it and the code is confusing, so i dunno... Let me ponder the other stuff in this for a day or two... Ali
On Feb 21, 2011, at 7:56 PM, Gabe Black wrote: > Actually digging a bit deeper, it looks like .m5 is where you put an > options.py script which you can use to add new command line options to > M5. That's set up in main.py, and a comment there says its for letting > people set default options, I suppose so you don't have to pass them on > the command line over and over. That's orthogonal to what I'm talking > about, I think, but if not please let me know. > > Gabe > > On 02/21/11 17:23, Gabe Black wrote: >> Hmm. Maybe we couldn't since SysPaths.py is a config file itself. Maybe >> it shouldn't be? Maybe we should build that into M5 directly? >> >> Gabe >> >> On 02/21/11 17:19, Gabe Black wrote: >>> 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 >> _______________________________________________ >> 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
