DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

[Klaus Schmidinger]

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?

Should a caller check against both EOPNOTSUPP *and* ENOTTY?

I searched through linux/drivers/media and found that both values are
used (EOPNOTSUPP 57 times and ENOTTY 71 times in the version I have in use).
While ENOTTY seems to apply here (at least from its description, not from
its name)

ENOTTY      "Inappropriate ioctl for device" (originally "Not a typewriter")

and I can see why this would be a reason for changing this, EOPNOTSUPP doesn't
really seem to apply, since there is, I assume, no "socket"
involved here:

EOPNOTSUPP  "Operation not supported on socket"

The value I would actually expect to be used in case an operation is
not supported by a device is

ENOTSUP     "Operation not supported"

Interestingly the driver source uses ENOTSUPP (note the double 'P') 8 times,
but that name is not defined according to man errno(3).

So the bottom line is that there appears to be some confusion as to which errno
value to return in case an operation is not supported.
Maybe all these return values should be set to ENOTSUP (with a single 'P' at the end)?

Klaus

Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

[Antti Palosaari]

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.

> Should a caller check against both EOPNOTSUPP *and* ENOTTY?

Current situation is a big mess. All the drivers are returning what 
error codes they wish. You simply cannot trust any error code.

> I searched through linux/drivers/media and found that both values are
> used (EOPNOTSUPP 57 times and ENOTTY 71 times in the version I have in
> use).
> While ENOTTY seems to apply here (at least from its description, not from
> its name)
>
> ENOTTY      "Inappropriate ioctl for device" (originally "Not a
> typewriter")
>
> and I can see why this would be a reason for changing this, EOPNOTSUPP
> doesn't
> really seem to apply, since there is, I assume, no "socket"
> involved here:
>
> EOPNOTSUPP  "Operation not supported on socket"

EOPNOTSUPP is usually used for unsupported I2C messages and that error 
should not be returned to the userspace. As mentioned, situation is 
total mess as there is very different error codes returned for 
unimplemented IOCTLs currently.

> The value I would actually expect to be used in case an operation is
> not supported by a device is
>
> ENOTSUP     "Operation not supported"
>
> Interestingly the driver source uses ENOTSUPP (note the double 'P') 8
> times,
> but that name is not defined according to man errno(3).
>
> So the bottom line is that there appears to be some confusion as to
> which errno
> value to return in case an operation is not supported.
> Maybe all these return values should be set to ENOTSUP (with a single
> 'P' at the end)?
>
> Klaus

Currently, for those old statistic IOCTLs there is two errors documented:
ENOTTY = IOCTL is not supported at all
EAGAIN = fronted is unable to perform IOCTL at the time (eg it is sleeping)

But in real life, drivers are returning very many different error codes 
and you could not trust. Maybe this will be changed slowly to documented 
error codes, during 5 or 10 years or so.

Surely it will not happen anytime soon unless someone has time to start 
looking demod driver by driver and changing error codes.

regards
Antti

-- 
http://palosaari.fi/

Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

[Manu Abraham]

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

>
>> Should a caller check against both EOPNOTSUPP *and* ENOTTY?
>
>
> Current situation is a big mess. All the drivers are returning what error
> codes they wish. You simply cannot trust any error code.


As you stated above, If a device doesn't have an IOCTL implemented, it
was returning EOPNOTSUPP for *any* driver that doesn't implement that
IOCTL. By changing it to ENOTTY, you broke existing applications.

How can a driver return an error code, for an IOCTL that is *not* implemented ?
AFAICS, your statement is bogus. :-)


Regards,
Manu

Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

[Antti Palosaari]

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.

If you do some searching you will easily find out a lot of discussions:
[1] http://www.makelinux.net/ldd3/chp-6-sect-1
[2] http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg14981.html
[3] http://linux.about.com/library/cmd/blcmdl2_ioctl.htm

>>> Should a caller check against both EOPNOTSUPP *and* ENOTTY?
>>
>>
>> Current situation is a big mess. All the drivers are returning what error
>> codes they wish. You simply cannot trust any error code.
>
>
> As you stated above, If a device doesn't have an IOCTL implemented, it
> was returning EOPNOTSUPP for *any* driver that doesn't implement that
> IOCTL. By changing it to ENOTTY, you broke existing applications.

There is a lot of drivers implementing stub callbacks and returning own 
values. Likely much more than those which does not implement it at all.

> How can a driver return an error code, for an IOCTL that is *not* implemented ?
> AFAICS, your statement is bogus. :-)

Just implementing IOCTL and returning some value! Have you looked those 
drivers?) There is very many different errors returned, especially in 
cases where hardware is not able to provide asked value at the time, 
example sleeping.

Maybe the most common status is just to return 0 as status and some 
random numbers as data - but there has been some discussion it is bad 
idea too.

It is just easy to fix back these few cases by implementing missing 
callbacks and return EOPNOTSUPP. But it will not "fix" all the drivers, 
only those which were totally without a callback.

And I ran RFC before started harmonizing error codes. There was not too 
many people commenting how to standardize these error codes....


regards
Antti
-- 
http://palosaari.fi/

Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

[Manu Abraham]

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.


Some drivers, have callbacks which are dummy as you state which
return different error codes ? It would have been easier, or correct to
fix those drivers, rather than blowing up all user applications.


> There is a lot of drivers implementing stub callbacks and returning own
> values. Likely much more than those which does not implement it at all.
>
>
>> How can a driver return an error code, for an IOCTL that is *not*
>> implemented ?
>> AFAICS, your statement is bogus. :-)
>
>
> Just implementing IOCTL and returning some value! Have you looked those
> drivers?) There is very many different errors returned, especially in cases
> where hardware is not able to provide asked value at the time, example
> sleeping.


When you implement an IOCTL callback, then you have an implemented
IOCTL. I still don't understand by what you state:

"ENOTTY is correct error code for the case IOCTL is not implemented."

in comparison to your above statement.

As i stated just above, it would be sensible to fix the drivers, rather than
causing even more confusion.


> Maybe the most common status is just to return 0 as status and some random
> numbers as data - but there has been some discussion it is bad idea too.
>
> It is just easy to fix back these few cases by implementing missing
> callbacks and return EOPNOTSUPP. But it will not "fix" all the drivers, only
> those which were totally without a callback.
>
> And I ran RFC before started harmonizing error codes. There was not too many
> people commenting how to standardize these error codes....


Just because no one commented, doesn't make it right to blow up userspace
applications.

Regards,
Manu

Re: [linux-media] Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

[Klaus Schmidinger]

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

Re: [linux-media] Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

[Mauro Carvalho Chehab]

Em Thu, 14 Feb 2013 22:33:40 +0100
Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> escreveu:

> 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.

You should also take a look on this one:
	[1] http://permalink.gmane.org/gmane.linux.kernel/1235728
and:
	[2] http://permalink.gmane.org/gmane.linux.kernel/1349845

So, yes, ENOTTY should be the proper error code for it.

> 
> 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...

Unfortunately, yes: fixing driver bugs that break application that
rely on it is a problem. As Linus said on [1]:

	"We may have to revert it if things get too nasty, 
	 but we should have done this years and years ago, so let's hope not."

I think we should revert Antti patch, until we're sure that all applications
are capable of working fine with ENOTTY. Only after that, we can remove the
bad usage of EOPNOTSUPP.

> 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...

Regards,
Mauro