> On 2011-03-18 13:57:35, Gabe Black wrote:
> > src/sim/syscall_emul.hh, line 503
> > <http://reviews.m5sim.org/r/589/diff/1/?file=11013#file11013line503>
> >
> >     Why is this change necessary? I'm not 100% sure why it was the way it 
> > was before, but I see no reason to change it either. Changing the fatal to 
> > a warn may be necessary to get some benchmark to run, but I'm talking 
> > specifically about the ones that would return -ENOTTY.
> 
> Vince Weaver wrote:
>     It's been a while, but let's see if I can see what's going on.
>     
>     Before we had a short list of ioctls we return -ENOTTY for, any not on 
> the list gave a fatal error.
>     
>     ENOTTY if I recall correctly is the typical way the kernel reports an 
> ioctl not being implemented.  So by changing all ioctls to warn and then 
> report ENOTTY we are saying that we don't support it, but the program can 
> keep running assuming it handles an ENOTTY properly.
>     
>     For most of the SPEC benchmarks ioctl() calls aren't important for 
> correctness, so this works.  
>     
>     We could go back to having a whitelist of known-to-be-OK-to-ignore 
> ioctls(), but it might turn out to be a lengthy list, and also we probably 
> should implement things like isatty() properly as I do think some benchmarks 
> depend on it returning the right value
>     (see http://www.cs.binghamton.edu/~msim/wiki/index.php/TIOCISATTY )
>

isatty is actually pretty annoying, and it's important that it -not- always 
return the right answer. It needs to be consistent regardless of whether your 
piping output to a file or watching it on the console so runs are 
deterministic, and if it always thinks it's going to a tty it'll buffer 
properly for when it's actually going to a tty (and doesn't look like 
something's broken, basically) and just perform a little worse when it's not. 
As far as simulator performance it doesn't matter since I'm sure it's a long 
way from being the critical path, and it should be a reasonable situation as 
far as simulated performance.

I think a whitelist is a good idea, and we don't have to have -all- the ok to 
ignore ones on there, just the ok to ignore ones that actually get called. That 
should be a lot more manageable list. That way you know if something out of the 
ordinary is happening (the simulator will bomb out) rather than something weird 
happening and the benchmark stumbling on to eventually die, potentially far 
from evidence of what happened. The later is a lot harder to debug.


- Gabe


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/589/#review981
-----------------------------------------------------------


On 2011-03-17 16:06:13, Lisa Hsu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/589/
> -----------------------------------------------------------
> 
> (Updated 2011-03-17 16:06:13)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> -------
> 
> X86 ioctl:  Another patch from Vince Weaver
> 
> 
> Diffs
> -----
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
>   src/sim/syscall_emul.hh 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/589/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Lisa
> 
>

_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to