I meant to add that changing the default behavior for unrecognized
ioctls from a fatal error to a warning is fine by me though.

Steve

On Wed, Sep 23, 2009 at 9:13 AM, Steve Reinhardt <[email protected]> wrote:
> For TTY-related ioctls, returning ENOTTY is the right behavior, so
> there's no need to print a warning.  To me it's a step backward to
> start printing a warning for something that we're actually handling
> correctly.  If we're not properly identifying which ioctls are
> TTY-related, I'd rather try and fix that than paper over it.
>
> Steve
>
> On Wed, Sep 23, 2009 at 8:55 AM, Ali Saidi <[email protected]> wrote:
>>
>> We don't do anything with the ioctl's at the moment, so picking certain
>> ones to do nothing with doesn't have much value. A warning is good as this
>> and the other functions that we're ignoring could be hiding bugs and it
>> would be nice to have the print statement to remind us it could be a
>> problem.
>>
>> Ali
>>
>>
>> On Wed, 23 Sep 2009 07:54:02 -0700, nathan binkert <[email protected]>
>> wrote:
>>> In general, I'm fine with ignoring things and hoping it works.  I
>>> think we should probably change the warn to warn_once.
>>>
>>> Similarly, some of the syscalls that we're ignoring should probably
>>> have a warning.
>>> Maybe unimplementedFunc should really just be warn_once plus return
>> error?
>>>
>>> Any other opinions?
>>>
>>>   Nate
>>>
>>>> The current ioctl implementation is somewhat BSD-centric.  The few IOCTL
>>>> values being checked have no Linux equivelant.  This changes things to
>>>> just assume that most ioctl's we'll see are tty related and just return
>>>> -ENOTTY.  This is enough for spec2k, though obviously not a good idea in
>>>> the long run.
>>>>
>>>>
>>>> diff -r 5ed84199f337 src/arch/x86/linux/syscalls.cc
>>>> --- a/src/arch/x86/linux/syscalls.cc    Mon Sep 21 23:06:05 2009 -0400
>>>> +++ b/src/arch/x86/linux/syscalls.cc    Mon Sep 21 23:16:41 2009 -0400
>>>> @@ -244,7 +244,7 @@
>>>>     /*  13 */ SyscallDesc("rt_sigaction", unimplementedFunc),
>>>>     /*  14 */ SyscallDesc("rt_sigprocmask", ignoreFunc),
>>>>     /*  15 */ SyscallDesc("rt_sigreturn", unimplementedFunc),
>>>> -    /*  16 */ SyscallDesc("ioctl", unimplementedFunc),
>>>> +    /*  16 */ SyscallDesc("ioctl", ioctlFunc<X86Linux64>),
>>>>     /*  17 */ SyscallDesc("pread64", unimplementedFunc),
>>>>     /*  18 */ SyscallDesc("pwrite64", unimplementedFunc),
>>>>     /*  19 */ SyscallDesc("readv", unimplementedFunc),
>>>> @@ -561,7 +561,7 @@
>>>>     /*  51 */ SyscallDesc("acct", unimplementedFunc),
>>>>     /*  52 */ SyscallDesc("umount2", unimplementedFunc),
>>>>     /*  53 */ SyscallDesc("lock", unimplementedFunc),
>>>> -    /*  54 */ SyscallDesc("ioctl", unimplementedFunc),
>>>> +    /*  54 */ SyscallDesc("ioctl", ioctlFunc<X86Linux32>),
>>>>     /*  55 */ SyscallDesc("fcntl", unimplementedFunc),
>>>>     /*  56 */ SyscallDesc("mpx", unimplementedFunc),
>>>>     /*  57 */ SyscallDesc("setpgid", unimplementedFunc),
>>>> diff -r 5ed84199f337 src/sim/syscall_emul.hh
>>>> --- a/src/sim/syscall_emul.hh   Mon Sep 21 23:06:05 2009 -0400
>>>> +++ b/src/sim/syscall_emul.hh   Mon Sep 21 23:16:41 2009 -0400
>>>> @@ -486,19 +486,11 @@
>>>>     }
>>>>
>>>>     switch (req) {
>>>> -      case OS::TIOCISATTY_:
>>>> -      case OS::TIOCGETP_:
>>>> -      case OS::TIOCSETP_:
>>>> -      case OS::TIOCSETN_:
>>>> -      case OS::TIOCSETC_:
>>>> -      case OS::TIOCGETC_:
>>>> -      case OS::TIOCGETS_:
>>>> -      case OS::TIOCGETA_:
>>>> -        return -ENOTTY;
>>>>
>>>>       default:
>>>> -        fatal("Unsupported ioctl call: ioctl(%d, 0x%x, ...) @
>> 0x%llx\n",
>>>> +        warn("Unsupported ioctl call: ioctl(%d, 0x%x, ...) @ 0x%llx\n",
>>>>               fd, req, tc->readPC());
>>>> +        return -ENOTTY;
>>>>     }
>>>>  }
>>>>
>>>> _______________________________________________
>>>> m5-dev mailing list
>>>> [email protected]
>>>> http://m5sim.org/mailman/listinfo/m5-dev
>>>>
>>>>
>>> _______________________________________________
>>> m5-dev mailing list
>>> [email protected]
>>> http://m5sim.org/mailman/listinfo/m5-dev
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to