I'd considered something along the lines of the map you're talking
about. Really ioctls should be associated with particular files instead
of an ISA as a whole, but setting up something like the syscalls where
there's an ignoreFunc and other functions which do something (if we even
need that now) could work.
Gabe
On 05/15/12 17:17, Marc Orr wrote:
> I did a little more digging around and have summarized the tty ioctls
> that the simulator has cared about, and how they are defined for each
> architecture in the linux repo (see below). I'm pretty confident that
> the _IOW and _IOR stuff works out to the hard-coded constants
> originally defined in the alpha linux.hh.
>
> I don't think a BSD flag will cut it. Also, ignoring ioctrls not
> defined for the current architecture seems like a poor solution as
> well. I would still lean towards something like the solution I posted
> (mostly because I think it is better than the other proposed options).
>
> Some other solutions:
> 1. Have each linux.hh keep a map describing the tty ioctls it cares about.
> 2. Make each tty ioctl a struct with a value plus a valid flag.
>
> All of the architectures include asm-generic/ioctls.h except for
> alpha. The values for alpha and powerpc are mostly the same (except
> alpha does include asm-generic/ioctls.h). The values in arm and x86
> are both derived from asm-generic. MIPS seems to have some of its own
> odd ball values.
>
> alpha, powerpc mips generic
> TIOCSETP _IOW('t', 9, struct sgttyb) 0x7409 -
> TIOCSETN _IOW('t', 10, struct sgttyb) 0x740a -
> TIOCSETC _IOW('t', 17, struct tchars) - -
> TIOCGETC _IOR('t', 18, struct tchars) - -
> FIONREAD _IOR('f', 127, int) 0x467f 0x541B
> TCSETAW _IOW('t', 25, struct termio) 0x5403 0x5407
> TCGETS _IOR('t', 19, struct termios) 0x540d 0x5401
> TCGETA _IOR('t', 23, struct termio) 0x5401 0x5405
>
> * from [linux/kernel/git/torvalds/linux.git] / arch / ### / include /
> asm / ioctls.h
> * ### is the architecture
>
> Also, the simulator has cared about TIOCISATTY, TIOCGETS, TIOCGETA.
> Oddly, I was unable to find these values in the latest linux repo.
>
> Marc
>
> On Mon, May 14, 2012 at 10:40 PM, Ali Saidi <[email protected]> wrote:
>>
>> On 14.05.2012 20:20, Steve Reinhardt wrote:
>>
>>> OK, it looks like
>> the TCGET/TCSET and FIONREAD ioctls are common, but most
>>> of the
>> TIOCGET/TIOCSET ones are only supported in some ISAs (but most ISAs
>> other than x86 and ARM):
>>>
>> http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?i=TIOCGETP
>>> I think
>> the TIOC* ioctls are BSD-derived, and since we started on Alpha and
>> Tru64 is BSD-derived, those ioctls were common. Then the other ISAs
>> mostly
>>> just blindly copied the Alpha code and as long as nothing broke
>> they were
>>> OK.
>>>
>>> It also looks like all the TIOC* ioctls have the
>> same definitions where
>>> they are defined (though the _IOR() and _IOW()
>> macros make that a little
>>> hard to verify).
>>>
>>> What about defining
>> all the ioctls in the common header, then just having a
>>> per-ISA flag
>> that says whether we care about the TIOC* ones or not? Or we
>>> could
>> just ignore all of them, on the assumption that Linux is unlikely to
>> re-use the codes for the TIOC* ioctls on x86 or ARM.
>>
>> Eitehr works for
>> me, but if we go with the prior, the definitions can just be put in
>> src/kern/linux/linux.hh.
>>
>>> Basically I'd like to see the solution that
>> has the minimum amount of
>>> redundancy and still works.
>>>
>>> Steve
>>>
>>>
>> On Mon, May 14, 2012 at 11:45 AM, Marc Orr <[email protected]> wrote:
>>>> To clarify my comment about the arm linux.hh file: It seems that a
>> couple of constants were updated to match the latest ioctls.h file that
>> Steve referenced, while the other constants that don't occur in that
>> file were left as is. Marc On Mon, May 14, 2012 at 11:40 AM, Marc Orr
>> <[email protected] [5]> wrote:
>>>>> Yes. so If you look at the file
>> that Steve referenced, many of the tty ioctrls we define for the other
>> archtectures don't occur. Also, I noticed that in the ARM linux.hh, the
>> constants look a little questionable to me. It almost looks like they
>> were copied and pasted from another architecture, and then a couple of
>> them were changed to be ARM specific. Marc On Mon, May 14, 2012 at 1:05
>> AM, Gabe Black <[email protected] [1]>
>>>> wrote:
>>>>
>>>>>> Oh, I
>> see. There are two header files, ioctls.h and ioctl.h (one has an s).
>> That's not confusing at all :-P. Gabe On 05/13/12 21:46, Steve Reinhardt
>> wrote:
>>>>>>> Looks like the latest kernel has all this in
>> there...
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/asm-generic/ioctls.h;h=199975fac395745342a6cabef1bfb612e73fc1dc;hb=HEAD
>> [6]
>>> _______________________________________________
>>> gem5-dev
>> mailing list
>> [email protected]http://m5sim.org/mailman/listinfo/gem5-dev
>>
>>
>>
>>
>> Links:
>> ------
>> [1] mailto:[email protected]
>> [2]
>> mailto:[email protected]
>> [3] mailto:[email protected]
>> [4]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>> [5]
>> mailto:[email protected]
>> [6]
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/asm-generic/ioctls.h;h=199975fac395745342a6cabef1bfb612e73fc1dc;hb=HEAD
>> [7]
>> mailto:[email protected]
>> [8] mailto:[email protected]
>> [9]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>> [10]
>> mailto:[email protected]
>> [11]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
