> On Oct. 19, 2016, 7:29 p.m., Steve Reinhardt wrote:
> > src/sim/fd_array.hh, line 140
> > <http://reviews.gem5.org/r/3676/diff/3/?file=61807#file61807line140>
> >
> >     Can't these be static variables and not per-instance? I don't see where 
> > they're modified after they're constructed.

I don't think that it's possible to initialize static variables with 
aggregates. I tried following through with this recommendation but I get 
"non-constant in-class initialization invalid for static member". I think that 
the aggregate initialization must be done at runtime, but for statics the 
resolution has to be done at compile time (just guessing).


- Brandon


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


On Oct. 18, 2016, 8:01 p.m., Brandon Potter wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3676/
> -----------------------------------------------------------
> 
> (Updated Oct. 18, 2016, 8:01 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 11699:c22ac97e3372
> ---------------------------
> 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/kern/tru64/tru64.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/SConscript 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/fd_array.hh PRE-CREATION 
>   src/sim/fd_array.cc PRE-CREATION 
>   src/sim/fd_entry.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/fd_entry.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/syscall_emul.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/syscall_emul.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> 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