Re: [PATCH] remove TCGETS

Linus; executive decision required please:

On Thu, 2003-08-14 at 08:54 -0700, Bryan Henderson wrote:
> <willy quoted SusV2 thusly>:
> >If an underlying device driver detects an error, then ioctl() shall fail
> if:
> >
> >[EINVAL]
> >    The request or arg argument is not valid for this device.
> >...
> >[ENOTTY]
> >    The fildes argument is not associated with a STREAMS device that
> >    accepts control functions.
> >...
> >Maybe we need to start removing ENOTTY returns from ioctl handlers.
> 
> How do you reach that conclusion from the above?  The specification is
> ambiguous.  When you send a TCGETS to a regular file, both the EINVAL and
> ENOTTY cases hold.
> 
> The actual spec is even more ambiguous, because it says at the top of the
> quoted section that the function described therein doesn't apply to
> anything but a STREAMS device, and therefore the implementation can do
> anything at all when you send a TCGETS to a regular file and still conform
> to that spec.
> 
> What's much more important than a spec, though, is convention.  There are
> probably programs that issue an ioctl to a file descriptor to find out if
> it is a terminal or not and expect the conventional ENOTTY for the "no"
> case and consider EINVAL an actual error.

And what's more important than convention is a ruling from the Chief
Penguin. 

LTP is bitching at me because my file system returns -EINVAL to all
ioctls instead of -ENOTTY. Do I...

 1. Make my file system return -ENOTTY.
 2. Make LTP accept -EINVAL instead of -ENOTTY on an invalid ioctl.
 3. Make LTP accept _either_ -EINVAL or -ENOTTY in that case.

I favour either #1 or #2 and don't care which. I dislike #3 because we
should be consistent.

cf. http://www.opengroup.org/onlinepubs/007904975/functions/ioctl.html

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html