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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux