[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
scons: *** Source `tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MOESI_hammer/stats.txt' not found, needed by target `build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer/status'. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. = Statistics differences =* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. *
[m5-dev] paths for disk images, kernels, etc.
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: extend dprintfs for RubyGenerated TraceFlag
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/492/#review877 --- Ship it! - Nilay On 2011-02-18 14:55:40, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/492/ --- (Updated 2011-02-18 14:55:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: extend dprintfs for RubyGenerated TraceFlag executing isnt a very descriptive debug message and in going through the output you get multiple messages that say executing but nothing to help you parse through the code/execution. So instead, at least print out the name of the action that is taking place in these functions. Diffs - src/mem/slicc/symbols/StateMachine.py bb35cb393bbb Diff: http://reviews.m5sim.org/r/492/diff Testing --- Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: extend dprintfs for RubyGenerated TraceFlag
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/492/#review878 --- Ship it! - Brad On 2011-02-18 14:55:40, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/492/ --- (Updated 2011-02-18 14:55:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: extend dprintfs for RubyGenerated TraceFlag executing isnt a very descriptive debug message and in going through the output you get multiple messages that say executing but nothing to help you parse through the code/execution. So instead, at least print out the name of the action that is taking place in these functions. Diffs - src/mem/slicc/symbols/StateMachine.py bb35cb393bbb Diff: http://reviews.m5sim.org/r/492/diff Testing --- Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org
Re: [m5-dev] paths for disk images, kernels, etc.
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
Re: [m5-dev] paths for disk images, kernels, etc.
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
Re: [m5-dev] paths for disk images, kernels, etc.
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... What's confusing? I added it mostly for me, but we can of course document it. options.py is just executed before main() is executed and it's done within the context of m5.main. You can in theory do anything you want in there, though the intent was to override default option values there. We could do something similar in SysPaths (exec .m5/paths.py) to set the default SysPaths. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
On 02/21/11 18:37, nathan binkert wrote: 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... What's confusing? I added it mostly for me, but we can of course document it. options.py is just executed before main() is executed and it's done within the context of m5.main. You can in theory do anything you want in there, though the intent was to override default option values there. We could do something similar in SysPaths (exec .m5/paths.py) to set the default SysPaths. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev I don't know if we should expect people to reach into main.py like that in a per user way. It does the job setting default values, but does anybody use that even? Nobody seems to have known it existed. I think setting an environment variable is a lot more straightforward than writing a python script that fiddles with M5's innards. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
I don't know if we should expect people to reach into main.py like that in a per user way. It does the job setting default values, but does anybody use that even? Nobody seems to have known it existed. I think setting an environment variable is a lot more straightforward than writing a python script that fiddles with M5's innards. It's not documented because it was never fleshed out. The idea was that the python script was more like a config file. I looked at it again, and all it does is export the options dict. In general, I think that it would be a good idea for us to have a config file or config directory and support that. I just used a python script, for what I did and I think that works pretty well in general since it's less code for us to write. That said, if we were to make it useful, we would have to document it better. I could be convinced to have a .ini file for configuration stuff though. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
On 02/21/11 20:14, nathan binkert wrote: I don't know if we should expect people to reach into main.py like that in a per user way. It does the job setting default values, but does anybody use that even? Nobody seems to have known it existed. I think setting an environment variable is a lot more straightforward than writing a python script that fiddles with M5's innards. It's not documented because it was never fleshed out. The idea was that the python script was more like a config file. I looked at it again, and all it does is export the options dict. In general, I think that it would be a good idea for us to have a config file or config directory and support that. I just used a python script, for what I did and I think that works pretty well in general since it's less code for us to write. That said, if we were to make it useful, we would have to document it better. I could be convinced to have a .ini file for configuration stuff though. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev Yeah, I think something like a config.ini for defaults would be a lot better. It wouldn't even really need to be as sophisticated as an ini file since there wouldn't be different sections. I can see that being useful. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
On Feb 21, 2011, at 10:15 PM, Gabe Black wrote: On 02/21/11 20:14, nathan binkert wrote: I don't know if we should expect people to reach into main.py like that in a per user way. It does the job setting default values, but does anybody use that even? Nobody seems to have known it existed. I think setting an environment variable is a lot more straightforward than writing a python script that fiddles with M5's innards. It's not documented because it was never fleshed out. The idea was that the python script was more like a config file. I looked at it again, and all it does is export the options dict. In general, I think that it would be a good idea for us to have a config file or config directory and support that. I just used a python script, for what I did and I think that works pretty well in general since it's less code for us to write. That said, if we were to make it useful, we would have to document it better. I could be convinced to have a .ini file for configuration stuff though. Nate Yeah, I think something like a config.ini for defaults would be a lot better. It wouldn't even really need to be as sophisticated as an ini file since there wouldn't be different sections. I can see that being useful. We could create a script and put it in the m5 root that emmitted python files into .m5 that properly setup the environment based on the user input. I rather like that idea and that way it could ask where various things were and we aren't setting a bunch of environment variables. I'm not a huge fan of the config.ini files because pretty much every thing we're going to want to add you need to add and check in three places. It would be better if it was just python that setup SysPaths and whatever else correctly. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
Three places does seem like a lot. What are they specifically? Hopefully we can get rid of one or two. That said, using python to generate python to put in a hidden directory to read with python embedded in a binary is, in my opinion, WAY more complicated than the problem warrants. The generating script would have to be fairly smart too so you could quickly update particular fields, remove previously set defaults, etc. How about a file with key value pairs separated by equals signs. Those would be used as the defaults when the options were set up, and that would be the whole deal. If somethings doesn't make sense as an option to the m5 binary, it wouldn't go in that file. There are a couple of things that follow from that. First, m5path would become an option to the binary which seems like a reasonable thing to do in its own right. That would mean we could eliminate the M5_PATH environment variable entirely, or leave it in somehow for compatibility. Second, there would potentially be a significant increase in the number of options the binary supports which could make --help less useful. We could define two levels of help, regular and verbose, like hg does I think. If we wanted to get fancy we could treat our file like hgrc and have one version in the repo, one in the home directory, and one system wide. Then they'd have to accumulate for paths and whatnot, I suppose. Gabe Quoting Ali Saidi sa...@umich.edu: We could create a script and put it in the m5 root that emmitted python files into .m5 that properly setup the environment based on the user input. I rather like that idea and that way it could ask where various things were and we aren't setting a bunch of environment variables. I'm not a huge fan of the config.ini files because pretty much every thing we're going to want to add you need to add and check in three places. It would be better if it was just python that setup SysPaths and whatever else correctly. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] paths for disk images, kernels, etc.
Quoting Ali Saidi sa...@umich.edu: Let me ponder the other stuff in this for a day or two... Ali Speaking of the other stuff, could anyone give a quick rundown of /dist? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
