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
