Re: [PATCH] remove TCGETS

[Andries Brouwer <aebr@win.tue.nl>]

On Tue, Oct 28, 2003 at 03:56:37PM +0000, David Woodhouse wrote:

> 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.

Short answer:

#3.

In the call ioctl(fd, SOMEIOCTL, arg) one should return ENOTTY
is fd is wrong, EINVAL if SOMEIOCTL or arg is wrong.


Long answer:

> > >[ENOTTY]
> > >    The fildes argument is not associated with a STREAMS device that
> > >    accepts control functions.

But you see that POSIX or SUSv* do not specify ioctl at all, except
insofar as it applies to STREAMS devices:

 For non-STREAMS devices, the functions performed by this call are unspecified.

So, if you want to decide what error return is appropriate in the
non-STREAMS case, neither POSIX nor SUSv* will help.

So, there are two sources of inspiration. Actual usage in BSD and
similar operating systems, and the POSIX definitions of the error numbers.
The latter are easy to quote:

[ENOTTY] 
    Inappropriate I/O control operation. A control function has been attempted
    for a file or special file for which the operation is inappropriate.

[EINVAL] 
    Invalid argument. Some invalid argument was supplied; for example, specifying
    an undefined signal in a signal() function or a kill() function.

Since both SOMEIOCTL and arg are arguments to the call ioctl(fd, SOMEIOCTL, arg),
it may not be forbidden to return EINVAL.

The POSIX spec mentions ENOTTY in the pages for ioctl, isatty, sockatmark,
tcdrain, tcflow, tcflush, tcgetattr, tcgetpgrp, tcgetsid, tcsendbreak,
tcsetattr, tcsetpgrp, ttyname. Typically ENOTTY points out that the fd parameter
is not a terminal, is not a controlling terminal, is not a socket.

An interesting text fragment is seen in the Rationale:
  [EFTYPE]  This error code was proposed in earlier proposals as
    ``Inappropriate operation for file type'', meaning that the operation
    requested is not appropriate for the file specified in the function call.
    This code was proposed, although the same  idea was covered by [ENOTTY],
    because the connotations of the name would be misleading. It was pointed out
    that the fcntl( ) function uses the error code [EINVAL] for this notion,
    and hence all instances of [EFTYPE] were changed to this code.

(Namely, for fcntl( ) the [EINVAL] description says: "... or fd refers to a file
 that does not support locking.")

My conclusion is that failing historical custom that would help choosing
between EINVAL and ENOTTY, we should choose EINVAL in all cases where
the decision to return an error was not based on the properties of fd.


Andries