> 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. > > Ali Saidi wrote: > 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. >
I don't think that's true. From an email I wrote about this on the 29th of last month: As far as the ioctl patch, I suspect the reason Vince Weaver wanted to nuke the cases present in ioctlFunc is that the constants they rely on don't exist in x86. They're defined for Alpha, MIPS, SPARC and powerpc, and in the file that uses them in the kernel (drivers/tty/tty_ioctl.c) conditionally compiles in the code that implements those calls based on if the constant is defined. Attaching the ioctl functions breaks the build because those constants aren't defined, and they aren't defined because there's nothing to set them to. - Gabe ----------------------------------------------------------- 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
