> 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. > > > Gabe Black wrote: > 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.
However, if you go on your favorite x86 machine and take a look at include: linux/ioctl.h includes x86_64-linux-gnu/asm/ioctl.h which includes asm-generic/ioctls.h the latter of which defines all those things like TCGETS - 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
