The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [RFC] Remove or convert empty ioctls ?
Date: Thu, 15 Oct 2009 18:28:12 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0910151756350.9428@localhost.localdomain> (raw)
In-Reply-To: <20091015164906.5b2c03db@lxorguk.ukuu.org.uk>

On Thu, 15 Oct 2009, Alan Cox wrote:
> Anyway the case discussed which is ".unlocked_ioctl = NULL" should return
> -ENOTTY, and there isn't any argument about the driver authors intentions.

I think we got some confusion finally. :)

If both unlocked_ioctl and ioctl are NULL the return code is -ENOTTY.

We have locked ioctl functions which return -ENOIOCTLCMD. vfs_ioctl()
returns that to user space, but for unlocked_ioctl it is translated to
-EINVAL. I guess we need to fix that either in the ioctl
implementations or let vfs_ioctl() translate it for locked ioctls as
well.

The other category of ioctls (both locked and unlocked) are the stub
functions which simply return -EINVAL or -ENOIOCTLCMD.

The spec says:
    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.

So for the stub ioctl functions EINVAL is a correct return value
because the driver has an ioctl function, but does not handle the
request.

But I completely agree, that we should remove those stubs simply
because they handle no request at all which is basically the same as
no ioctl function.

Thanks,

	tglx

  parent reply	other threads:[~2009-10-15 16:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-15  9:20 [RFC] Remove or convert empty ioctls ? Thomas Gleixner
2009-10-15 12:12 ` Jeff Garzik
2009-10-15 15:01   ` Alan Cox
2009-10-15 15:22     ` Jeff Garzik
2009-10-15 15:31       ` Alan Cox
2009-10-15 15:35         ` Jeff Garzik
2009-10-15 15:49           ` Alan Cox
2009-10-15 16:03             ` Jeff Garzik
2009-10-15 16:23               ` Thomas Gleixner
2009-10-15 16:28             ` Thomas Gleixner [this message]
2009-10-15 15:50           ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.0910151756350.9428@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=fweisbec@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox