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
