[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110628174223.3d78ca4c@lxorguk.ukuu.org.uk>
Date: Tue, 28 Jun 2011 17:42:23 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Hans Verkuil <hverkuil@...all.nl>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Sakari Ailus <sakari.ailus@....fi>,
Arnd Bergmann <arnd@...db.de>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl
doesn't exist
> (In fact, the _correct_ thing to do would probably be to just do
>
> #define ENOIOCTLCMD ENOTTY
>
> and get rid of any translation - just giving ENOTTY a more appropriate
> name and less chance for confusion)
Some code uses the two to separate 'the driver specific helper code
doesn't handle this' and 'does handle this'. In that situation you take
away the ability of a driver to override a midlayer ioctl with -ENOTTY to
say "I don't support this even if most people do"
> There may be applications out there that really break when they get
> ENOTTY instead of EINVAL. But most cases that check for errors from
> ioctl's tend to just say "did this succeed or not" rather than "did
> this return EINVAL". That's *doubly* true since the error code has
> been ambiguous, so checking for the exact error code has always been
> pretty pointless.
Chances are if anything is busted its busted the other way on Linux and
expects -ENOTTY. Certainly the large number I've been fixing over time
haven't shown up any problems.
--
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