I'm pretty close to having an X86_FS regression basically ready to go, and one of the issues I had to straighten out was that the way the default x86 root was configured was a little hacky and would always clobber whatever other image was specified. The idea to use the default settings gets substituted for the actual default settings early enough in the existing scripts that you really need to make the SysConfig object select the right image based on the ISA you're building in buildEnv. This seems a little hacky, and it's fairly inflexible as far as expanding ISA options to ones we already support or may support in the future. I'd like to create a subdirectory in the existing directories that are for kernel images and disk images named after whatever arch they go with. There shouldn't be any ambiguity since it seems very unlikely root disk images or kernels would be interchangeable across architectures. Then, when using the default disk image, the buildEnv would be inserted into the path and select an image or kernel with a standard name and get what it needs. This still leaves the dependence on buildEnv which would be nice to factor out, but I think it's a step in the right direction. Any thoughts and/or alternative suggestions? One other possibility that just occurred to me would be to set up some symlinks or persistent variables in the scripts at an early/low level that would have paths to these magic directories in them. Then we could bury the dependence on buildEnv down in the bowels of something where that sort of mid to low level hook probably belongs.
Also, while thinking about this, I realized this could make it harder to support, say, 32 bit and 64 bit versions of x86 Linux since there would be only one default file name for the root disk image. This is a problem in the regressions as well. Perhaps we should adopt the idea of an ISA variant where it's still x86 or SPARC or ARM, but it's further specialized into 32 or 64 bit, 32 or 64 bit or virtualized, thumb or ARM, etc. This fits with my second idea above better than the first. Anyway, I don't really have any strong suggestions or blocking problems here, this just looked like something that could use some organizing. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
