> On May 11, 2012, 10:33 p.m., Steve Reinhardt wrote: > > Marc, can you explain why you split these out to be per-ISA instead of > > common (at least for the linuxes)? I see that the x86 code is different, > > but I don't understand why it's different.
Following up here it seems like all the ioctls that at least now all these are defined in /usr/include/asm-generic. They should be the same for all Linux ISAs. I don't know if this was always the case, but it seems reasonable that the issue here was Tru64 vs Linux. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1187/#review2681 ----------------------------------------------------------- On May 11, 2012, 5:17 p.m., Marc Orr wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1187/ > ----------------------------------------------------------- > > (Updated May 11, 2012, 5:17 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 8979:165c23d33161 > --------------------------- > x86 syscall emulation: Add the TCGETS ioctl to the whitelist of tty ioctls > that > return -ENOTTY. > > This patch is a revised version of Vince Weaver's patch from 589. > > > Diffs > ----- > > src/arch/alpha/linux/linux.hh 4388495beb44ba859d20177371caf9e14902ef91 > src/arch/alpha/tru64/tru64.hh 4388495beb44ba859d20177371caf9e14902ef91 > src/arch/arm/linux/linux.hh 4388495beb44ba859d20177371caf9e14902ef91 > src/arch/mips/linux/linux.hh 4388495beb44ba859d20177371caf9e14902ef91 > src/arch/power/linux/linux.hh 4388495beb44ba859d20177371caf9e14902ef91 > src/arch/x86/linux/linux.hh 4388495beb44ba859d20177371caf9e14902ef91 > src/arch/x86/linux/syscalls.cc 4388495beb44ba859d20177371caf9e14902ef91 > src/sim/syscall_emul.hh 4388495beb44ba859d20177371caf9e14902ef91 > > Diff: http://reviews.gem5.org/r/1187/diff/ > > > Testing > ------- > > Ran perlbench to confirm that that the workload is not held up by this ioctl. > Furthermore, ran all spec workloads as best I could to confirm that there are > no more ioctls called from them. Some of the inputs available to me were too > large to run all workloads to completion. Also, some of workloads fail due to > other causes. But I am fairly confident that this is the only ioctl that was > causing problems. > > Also, ran the regression tester to confirm that everything compiles. I still > need to examine the output a little more carefully to make sure everything > passes. > > > Thanks, > > Marc Orr > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
