From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andries Brouwer Subject: Re: [PATCH] remove TCGETS Date: Tue, 28 Oct 2003 21:52:42 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20031028205242.GA10910@win.tue.nl> References: <1067356596.15551.448.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bryan Henderson , torvalds@osdl.org, Matthew Wilcox , Peter Braam , intermezzo-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Return-path: Received: from kweetal.tue.nl ([131.155.3.6]:20497 "EHLO kweetal.tue.nl") by vger.kernel.org with ESMTP id S261271AbTJ1UxO (ORCPT ); Tue, 28 Oct 2003 15:53:14 -0500 To: David Woodhouse Content-Disposition: inline In-Reply-To: <1067356596.15551.448.camel@hades.cambridge.redhat.com> List-Id: linux-fsdevel.vger.kernel.org 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