From: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>
To: linux-media@vger.kernel.org
Subject: Re: [linux-media] Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
Date: Thu, 14 Feb 2013 22:33:40 +0100 [thread overview]
Message-ID: <511D5834.2030002@tvdr.de> (raw)
In-Reply-To: <CAHFNz9+1w2W0dc9ZrW7mewA7aB4YbuJW7QT5Pr7-m2Js9vpq8A@mail.gmail.com>
On 14.02.2013 20:50, Manu Abraham wrote:
> On Fri, Feb 15, 2013 at 12:46 AM, Antti Palosaari <crope@iki.fi> wrote:
>> On 02/14/2013 08:05 PM, Manu Abraham wrote:
>>>
>>> On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari <crope@iki.fi> wrote:
>>>>
>>>> On 02/14/2013 03:12 PM, Klaus Schmidinger wrote:
>>>>>
>>>>>
>>>>> In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device
>>>>> (using stb0899).
>>>>> After this call I check 'errno' for EOPNOTSUPP to determine whether this
>>>>> device supports this call. This used to work just fine, until a few
>>>>> months
>>>>> ago I noticed that my devices using stb0899 didn't display their signal
>>>>> quality in VDR's OSD any more. After further investigation I found that
>>>>> ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but
>>>>> rather
>>>>> ENOTTY. And since I stop getting the signal quality in case any unknown
>>>>> errno value appears, this broke my signal quality query function.
>>>>>
>>>>> Is there a reason why this has been changed?
>>>>
>>>>
>>>>
>>>> I changed it in order to harmonize error codes. ENOTTY is correct error
>>>> code
>>>> for the case IOCTL is not implemented. What I think it is Kernel wide
>>>> practice.
>>>>
>>>
>>> By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed
>>> to
>>> break User ABI. https://lkml.org/lkml/2012/12/23/75
>>
>>
>> Yes, it will change API, that's clear. But the hell, how you will get
>> anything fixed unless you change it? Introduce totally new API every-time
>> when bug is found? You should also understand that changing that single
>> error code on that place will not change all the drivers and there will be
>> still some other error statuses returned by individual drivers.
>>
>> It is about 100% clear that ENOTTY is proper error code for unimplemented
>> IOCTL. I remember maybe more than one discussion about that unimplemented
>> IOCTL error code. It seems to be defined by POSIX [1] standard.
>
>
> It could be. But what I stated is thus:
>
> There existed commonality where all unimplemented IOCTL's returned
> EOPNOTSUPP when the corresponding callback wasn't implemented.
> So, this was kind of standardized though it was not the ideal thing,
> though it was not a big issue, it just stated "socket" additionally.
>
> You changed it to ENOTTY to make it fit for the idealistic world.
> All applications that depended for ages, on those error are now broken.
I'm sorry I stirred up this topic again. I wasn't aware that *this* was
the reason for https://lkml.org/lkml/2012/12/23/75.
As an application developer myself I don't mind if bugs in drivers are
fixed, I just wanted to understand the rationale. So now I've learned
that bugs in drivers can't be fixed, because some software might rely
on the bug. Oh well...
In this particular function of VDR I have now changed things to no longer
check for any particular "not supported" errno value, just EINTR. I hope
that one is standardized enough...
Klaus
next prev parent reply other threads:[~2013-02-14 21:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-14 13:12 DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS) Klaus Schmidinger
2013-02-14 15:52 ` Antti Palosaari
2013-02-14 18:05 ` Manu Abraham
2013-02-14 19:16 ` Antti Palosaari
2013-02-14 19:50 ` Manu Abraham
2013-02-14 21:33 ` Klaus Schmidinger [this message]
2013-02-15 14:10 ` [linux-media] " Mauro Carvalho Chehab
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=511D5834.2030002@tvdr.de \
--to=klaus.schmidinger@tvdr.de \
--cc=linux-media@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).