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