[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091015163103.5e42fabe@lxorguk.ukuu.org.uk>
Date: Thu, 15 Oct 2009 16:31:03 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Jeff Garzik <jeff@...zik.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Remove or convert empty ioctls ?
On Thu, 15 Oct 2009 11:22:40 -0400
Jeff Garzik <jeff@...zik.org> wrote:
> On 10/15/2009 11:01 AM, Alan Cox wrote:
> >> "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.
> >
> > We've changed lots of them to -ENOTTY over the past few years, nobody has
> > even noticed (you included ;))
> >
> > SuS says an unknown ioctl code returns -ENOTTY.
>
> These are not unknown ioctls; they are ioctls that the driver author
> close to implement rather than the default (ENOTTY).
That makes them ENOTTY please go and read the standards document.
EINVAL means you used an ioctl that is correct for the driver but that
for some reason the driver didn't like it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists