On Mon, Mar 31, 2008 at 2:41 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
> > UPDATE: I made the close() syscall in SE mode gives a warning and
> ignores
> > the call when the argument is between
> > 0 and 2 (stdin, stdout, stderr).
> Seems like a good idea. If there is some sort of mapping in the
> syscall layer that says that they're valid fds, you might want to
> remove that.
I agree... I think the basic idea is good, but a better implementation would
be to always remove the entry from the Process::fd_map array regardless of
the target's fd, but only call close on the simulator fd if it's not 0, 1,
or 2. (Strictly speaking you wouldn't want to close any fd that's shared
between processes, but that's more work and I don't think it's even possible
to share any other fds until we implement fork().)
Looking at closeFunc(), it actually seems backward to me in that light:
int status = close(p->sim_fd(target_fd));
if (status >= 0)
p->free_fd(target_fd);
Maybe should be more like:
int status;
int sim_fd = p->sim_fd(target_fd);
if (sim_fd < 0)
status = -1;
else if (sim_fd > 2)
status = close(sim_fd);
else
status = 0;
if (status >= 0)
p->free_fd(target_fd);
> > UPDATE: I made the exit() function in cpu/thread_context.hh checks to
> see if
> > other CPUs (and/or threads) are alive
> > before returning 1 and telling the simulation to exit. I had done
> > something similar for O3. (although it just does this
> > for the CPU so it probably doesnt work for non-SMT, multiprogrammed
> > workloads that want to run to completion)
>
> Seems that this should be a parameter to the workload object since
> people might want both options.
Yea, it should definitely be a parameter... maybe a system parameter rather
than a workload parameter though (since in multi-programmed workloads you
actually have multiple workload objects).
Steve
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
