Review Board 2.0.15

syscall_emul: create Process output files in output dir

Review Request #3076 - Created Aug. 23, 2015 and updated

Steve Reinhardt
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.


Issue Summary

1 0 0 1
Description From Last Updated Status
Ship it!
Posted (Aug. 24, 2015, 9:05 a.m.)
Great. The way it should be.
Posted (Aug. 26, 2015, 7:42 a.m.)

I'm not arguing against this patch, but I do see the original rationale. Running a binary natively, or appending "gem5.opt -c" in front of the binary will produce the same outputs. I don't think I have an opinion one way or the other.

  1. 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.


  2. 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.

  3. 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.

Posted (Aug. 27, 2015, 11:35 a.m.)

src/sim/ (Diff revision 1)


  1. Sorry, Sooraj and I were talking about the "Fix It and Ship It" option on Reviewboard and I accidentally posted this review. :(

Ship it!
Posted (Aug. 28, 2015, 6:54 a.m.)

I think this makes sense since it makes the behaviour consistent with gem5's std(out|err) redirection.