Which error code to return when a usb camera gets unplugged
Hi,
While working on my cleanup / v4l2 compliance series for the pwc driver I've noticed that the pwc and gspca drivers are doing different things wrt what error they return to an app is using the device while it gets unplugged. gspca returns -ENODEV, where as pwc returns -EPIPE.
Both make some sense. I've not looked at what other usb (or other hotplug capable bus) v4l2 drivers do, but it makes sense to me to standardize on an error here, preferably a reasonable unique one so that apps can detect unplug versus other errors. Note that the usb subsystem returns -ENODEV when you try to (re)submit an urb from its completion handler, when that completion handler gets called because the urb was unlinked because of device unplug.
Given that we often return usb error codes unmodified and the usb subsys uses -ENODEV for trying to do things with unplugged devices, I guess it makes sense for us to also use -ENODEV.
Regards,
Hans
Quoted 18 lines · Hans de Goede
Hi,
While working on my cleanup / v4l2 compliance series for the pwc driver I've noticed that the pwc and gspca drivers are doing different things wrt what error they return to an app is using the device while it gets unplugged. gspca returns
-ENODEV, where as pwc returns-EPIPE.Both make some sense. I've not looked at what other usb (or other hotplug capable bus) v4l2 drivers do, but it makes sense to me to standardize on an error here, preferably a reasonable unique one so that apps can detect unplug versus other errors. Note that the usb subsystem returns
-ENODEVwhen you try to (re)submit an urb from its completion handler, when that completion handler gets called because the urb was unlinked because of device unplug.
Quoted 4 lines
Given that we often return usb error codes unmodified and the usb subsys uses
-ENODEVfor trying to do things with unplugged devices, I guess it makes sense for us to also use-ENODEV.
I'm pretty sure ENODEV is what gets returned today if you attempt to open a /dev/videoX node for a device that has been disconnected but the device node hasn't yet been removed. So I would agree that ENODEV is a good choice for the scenario you described.
Devin
Signature · 2 lines
Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com
Quoted 24 lines · Devin Heitmueller
Quoted 18 lines · Hans de Goede
Hi,
While working on my cleanup / v4l2 compliance series for the pwc driver I've noticed that the pwc and gspca drivers are doing different things wrt what error they return to an app is using the device while it gets unplugged. gspca returns
-ENODEV, where as pwc returns-EPIPE.Both make some sense. I've not looked at what other usb (or other hotplug capable bus) v4l2 drivers do, but it makes sense to me to standardize on an error here, preferably a reasonable unique one so that apps can detect unplug versus other errors. Note that the usb subsystem returns
-ENODEVwhen you try to (re)submit an urb from its completion handler, when that completion handler gets called because the urb was unlinked because of device unplug.Quoted 4 lines
Given that we often return usb error codes unmodified and the usb subsys uses
-ENODEVfor trying to do things with unplugged devices, I guess it makes sense for us to also use-ENODEV.
Quoted 4 lines
I'm pretty sure ENODEV is what gets returned today if you attempt to open a
/dev/videoXnode for a device that has been disconnected but the device node hasn't yet been removed. So I would agree that ENODEV is a good choice for the scenario you described.
Neither ENODEV nor EPIPE are correct. POSIX requires ENXIO in this situation.
http://pubs.opengroup.org/onlinepubs/9699919799/
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03
Section 2.3 describes the error numbers. Here are some highlights:
[EIO]
Input/output error. Some physical input or output error has occurred. This error may be reported on a subsequent operation on the same file descriptor. Any other error-causing operation on the same file descriptor may cause the [EIO] error indication to be lost.
[ENODEV]
No such device. An attempt was made to apply an inappropriate function to a device; for example, trying to read a write-only device such as a printer.
[ENXIO]
No such device or address. Input or output on a special file refers to a device that does not exist, or makes a request beyond the capabilities of the device. It may also occur when, for example, a tape drive is not on-line.
[EPIPE]
Broken pipe. A write was attempted on a socket, pipe, or FIFO for which there is no process to read the data.
Also, Appendix A of
"POSIX and Linux Application Compatibility Design Rules"
has this note:
"Formerly, Linux permited several file system functions to return either ENODEV or ENXIO for a non-existent device, while POSIX requires an ENXIO return in this case. Linux now returns the correct error under this condition. This applied to fopen(), freopen(), open(), and creat()."
Regards,
Andy