> On Sept. 21, 2011, 10:19 p.m., Steve Reinhardt wrote: > > new_tests/conftest.py, line 81 > > <http://reviews.gem5.org/r/834/diff/1/?file=14762#file14762line81> > > > > as I mention below, I'd prefer to see us use the existing > > configs/example scripts by default, so it might be nice to build a command > > line here that doesn't directly involve the test infrastructure (other than > > locating inputs and outputs) > > Ali Saidi wrote: > So I actually played with this some more recently and got hello world > working running from the command line. However, the process convinced me that > we don't actually want to run gem5 from the command line via the existing > scripts. Perhaps there should be regression tests that do, but they should > exist to test the config scripts and not be a requirement for all tests. > > The primary reason I came to this conclusion is that we throw a lot of > information away when placing things on the command line and we don't get to > have error handling in python scripts communicate information back to the > simulator in a nice way. For example, we've talked a lot about if a input > file doesn't exist we should skip the test (as opposed to reporting pass or > fail). If we look at how cpu2000.py handles files not found it raises an > exception. This flows back to se.py where we panic on the exception. I think > it would be much nicer if the test infrastructure caught the exception when > the LiveProcess was being created as opposed to trying to do some string > matching on stderr or perhaps defining certain return codes that means "input > file not found." > > Thoughts?
My main thought is that I'm glad to see you're back to looking at this again... thank you thank you! I see your point and it's a good one. My main thing is not just being able to test the config scripts but perhaps even more avoiding the redundancy of having a bunch of similar-but-different config scripts used only for tests like we do know. So it's less about invoking se.py or fs.py than making sure that we use the configs/common scripts rather than duplicating their functionality elsewhere. Ideally we might end up refactoring code between configs/example and configs/common to maximize reuse. Does that seem like it would work? - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/834/#review1555 ----------------------------------------------------------- On Aug. 30, 2011, 10:48 a.m., Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/834/ > ----------------------------------------------------------- > > (Updated Aug. 30, 2011, 10:48 a.m.) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Description > ------- > > Regressions: Start of new regression system > > This code is to start a discussion around how to implement the next > regression system for gem5. Attached is a simple example that doesn't > run gem5 yet, but is getting closer. The big question here is how to > build up configuration files to hopefully minimize duplication of code. > > > Diffs > ----- > > new_tests/conftest.py PRE-CREATION > new_tests/hello_world/test_hello.py PRE-CREATION > > Diff: http://reviews.gem5.org/r/834/diff/diff > > > Testing > ------- > > > Thanks, > > Ali Saidi > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
