On 05/13/12 17:57, Ali Saidi wrote:
>
>> 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

The copy of /usr/include/asm-generic/ioctl.h I have on my laptop is
attached and doesn't seem to define any of those. It has a set of macros
for building up IOCTL constants which could be used if those particular
calls had numbers assigned to them, but they don't seem to as far as I
was able to find. My digging around in the kernel strongly suggested
that most of those constants were deprecated and left out of certain
architectures, but I don't have much prior knowledge of IOCTLs or how
they're supposed to be set up.

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

Reply via email to