-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3676/#review9137
-----------------------------------------------------------



src/sim/process.cc (line 228)
<http://reviews.gem5.org/r/3676/#comment7863>

    Please add in a warning.



src/sim/process.cc (line 249)
<http://reviews.gem5.org/r/3676/#comment7864>

    Please add in a warning.



src/sim/syscall_emul.hh (line 989)
<http://reviews.gem5.org/r/3676/#comment7865>

    I see you added getSimFD() to the base class, but it still looks like you 
have some unnecessary dynamic casts laying around.


- Michael LeBeane


On Nov. 16, 2016, 5:59 p.m., Brandon Potter wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3676/
> -----------------------------------------------------------
> 
> (Updated Nov. 16, 2016, 5:59 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 11717:7f3bf41cce5c
> ---------------------------
> syscall_emul: [patch 10/22] refactor fdentry and add fdarray class
> 
> Several large changes happen in this patch.
> 
> The FDEntry class is rewritten so that file descriptors now correspond to
> types: 'Regular' which is normal file-backed file with the file open on the
> host machine, 'Pipe' which is a pipe that has been opened on the host machine,
> and 'Device' which does not have an open file on the host yet acts as a pseudo
> device with which to issue ioctls. Other types which might be added in the
> future are directory entries and sockets (off the top of my head).
> 
> The FDArray class was create to hold most of the file descriptor handling
> that was stuffed into the Process class. It uses shared pointers and
> the std::array type to hold the FDEntries mentioned above. The implementation
> could use a review; I feel that there's some room for improvement, but it
> seems like a decent first step.
> 
> The changes to these two classes needed to be propagated out to the rest
> of the code so there were quite a few changes for that. Also, comments were
> added where I thought they were needed to help others and extend our
> DOxygen coverage.
> 
> 
> Diffs
> -----
> 
>   src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/fd_entry.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/fd_entry.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/fd_array.hh PRE-CREATION 
>   src/sim/fd_array.cc PRE-CREATION 
>   src/sim/SConscript c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/gpu-compute/cl_driver.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/kern/tru64/tru64.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3676/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to