> On Aug. 26, 2015, 2:42 p.m., Jason Power wrote: > > I'm not arguing against this patch, but I do see the original rationale. > > Running a binary natively, or appending "gem5.opt config.py -c" in front of > > the binary will produce the same outputs. I don't think I have an opinion > > one way or the other. > > Steve Reinhardt wrote: > Good point---obviously this change works better for my use case, but I > can see the confusion you point out. In particular, I can imagine a case > where a program creates an output file, then closes and re-opens it, and the > re-open will fail since the file did not get created in the cwd. So now I > sort of feel like this ought to be controlled with a command-line flag. > Another alternative would be to have an option to force a cwd change into the > output directory, which I think would make this change irrelevant (since > output files would then automatically get created in the output dir) and also > solve the create/re-open problem, and would only be an issue if your program > is reading files in the original dir, but if you specified the cd option then > presumably you'd know that you need to fix that. > > Thoughts? > > Joel Hestness wrote: > I wasn't sure how to feel about this patch. The current output file setup > is consistent in that all files specified on the command line to the gem5 > binary can use the same relative file paths (e.g. outdir, benchmark > input/output, simulator output), so it's easy to reason about. That said, I > understand that some benchmarks implicitly specify input and output files and > these are often harder to change than the simulator. > > Of the options to change output file handling, I feel that a command line > option to run from the output directory (default: False) is most desirable, > since it doesn't upset any existing scripts.
I think having an option is a good idea. In fact, there could be two different ways to run gem5. 1) In "wrapper" mode, where output is sent to stdout/stderr and files are read/written in cwd. This would be similar to how docker/pin/etc. works, for instance. 2) In redirect mode where everything (or a subset) is redirected to m5out. I'm not sure if this totally lines up with what you were saying, Steve. I personally think I would use it similar to your use case anyway. - Jason ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3076/#review7053 ----------------------------------------------------------- On Aug. 24, 2015, 6:56 a.m., Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3076/ > ----------------------------------------------------------- > > (Updated Aug. 24, 2015, 6:56 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11064:98f8322edfdb > --------------------------- > syscall_emul: create Process output files in output dir > > Redirected output files from Process objects were being created in > the current directory instead of in the output directory. > > > Diffs > ----- > > src/sim/process.cc 842f56345a421244a7a8988a5bc4fb1cfbf409ef > > Diff: http://reviews.gem5.org/r/3076/diff/ > > > Testing > ------- > > > Thanks, > > Steve Reinhardt > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
