I never messed around with the ioctl stuff. What do other M5 devs think?
Nate? Steve? Ali?
Gabe
Vince Weaver wrote:
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
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
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.
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
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 ste...@gmail.com wrote:
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to
On Wed, 23 Sep 2009, nathan binkert wrote:
In general, I'm fine with ignoring things and hoping it works. I
think we should probably change the warn to warn_once.
I think that's a good idea.
Similarly, some of the syscalls that we're ignoring should probably
have a warning.
Maybe
On Wed, 23 Sep 2009, Steve Reinhardt 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
On Wed, Sep 23, 2009 at 2:53 PM, Vince Weaver vi...@csl.cornell.edu wrote:
On Wed, 23 Sep 2009, Steve Reinhardt 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
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
Quoting nathan binkert n...@binkert.org:
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
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
11 matches
Mail list logo
