On Thursday, January 06, 2011 23:19:12 Greg KH wrote:
<snip>
> > > > +static ssize_t media_read(struct file *filp, char __user *buf,
> > > > + size_t sz, loff_t *off)
> > > > +{
> > > > + struct media_devnode *mdev = media_devnode_data(filp);
> > > > +
> > > > + if (!mdev->fops->read)
> > > > + return -EINVAL;
> > > > + if (!media_devnode_is_registered(mdev))
> > > > + return -EIO;
> > >
> > > How could this happen?
> >
> > This can happen when a USB device is disconnected for instance.
>
> But what's to keep that from happening on the next line as well?
Nothing.
> That
> doesn't seem like a check you can ever be sure about, so I wouldn't do
> it at all.
Actually, there is a reason why this was done for v4l (and now the media
API): typically, once a USB disconnect happens V4L drivers will call
video_unregister_device() which calls device_unregister. Afterwards the
device node should reject any new file operations except for release().
Obviously, this check can be done in the driver as well, but doing this
check in the V4L core has the advantage of 1) consistent return codes and
2) drivers no longer have to check.
Of course, since the disconnect can happen at any time drivers still need
to be able to handle errors from the USB subsystem due to disconnects, but
that is something they always have to do.
>
> > > And are you sure -EIO is correct?
> >
> > -ENXIO is probably better (I always confuse that with -ENODEV).
I wondered why V4L uses -EIO and I think it is related to the V4L2 specification
of the read() function:
EIO
I/O error. This indicates some hardware problem or a failure to communicate with
a remote device (USB camera etc.).
Well, I guess a disconnect can be seen as a failure to communicate :-)
I think that ENODEV is much better. After all, there is no device
anymore after a disconnect.
Is there some standard for this?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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
