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
