Re: Which error code to return when a usb camera gets unplugged

[Andy Walls <awalls@md.metrocast.net>]

On Mon, 2011-06-06 at 13:59 -0400, Devin Heitmueller wrote:
> On Mon, Jun 6, 2011 at 1:56 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > 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.
> 
> 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.

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"

https://www.opengroup.org/platform/single_unix_specification/uploads%/40/13450/POSIX_and_Linux_Application_Compatibility_Final_-_v1.0.pdf

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