Em Thu, 14 Feb 2013 22:33:40 +0100 Klaus Schmidinger <Klaus.Schmidinger@xxxxxxx> escreveu: > On 14.02.2013 20:50, Manu Abraham wrote: > > On Fri, Feb 15, 2013 at 12:46 AM, Antti Palosaari <crope@xxxxxx> wrote: > >> On 02/14/2013 08:05 PM, Manu Abraham wrote: > >>> > >>> On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari <crope@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
