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
next prev parent 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.