All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	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 08:12:44 -0400	[thread overview]
Message-ID: <4AD711BC.2030409@garzik.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0910151113340.9428@localhost.localdomain>

On 10/15/2009 05:20 AM, Thomas Gleixner wrote:
> Hi,
>
> while looking into pushing down BKL to ioctls I noticed that we have a
> lot of ioctls which simply return -EINVAL or some other fancy error
> code.
>
> The question is whether we should convert them to unlocked_ioctl or
> simply remove them and let the sys_ioctl code return the default
> -ENOTTY error code.
>
> One could argue that this is a user visible change, but OTOH there is
> no particular value of EINVAL or any other weird error code when it
> just says: there is no ioctl for this fd.

It seems like a mistake to generalize a rule out of this, especially if 
it leads to error return values changing unexpectedly in years-old code.

"no particular value" is highly subjective, and I think unprovable, 
without an exhaustive survey of userland programs interacting with 
kernel drivers.  Userland programs often interact with a -class- of 
drivers, expecting predictable behavior from a DoThisThing ioctl, with 
EINVAL or "other weird error code" returned intentionally.

Changing the return codes seems quite unwise.

	Jeff





  reply	other threads:[~2009-10-15 12:13 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 [this message]
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
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=4AD711BC.2030409@garzik.org \
    --to=jeff@garzik.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.