Hans Verkuil wrote:
...
+ if (!subscribed) {
+ ret = -EIO;
Shouldn't this be -ENOENT?
If I use -ENOENT, having no events subscribed is indistinguishable
form no events pending condition. Combine that with using select(2),
and you can no longer distinguish having no events subscribed from
the case where you got an event but someone else (another thread or
process) dequeued it.
OK, but then your commit message is out of sync with the actual patch since
the commit log says ENOENT.
-EIO makes that explicit --- this also mirrors the behaviour of
VIDIOC_DQBUF. (And it must be documented as well, which is missing
from the patch currently.)
I don't like using EIO for this. EIO generally is returned if a hardware
error or an unexpected hardware condition occurs. How about -ENOMSG? Or
perhaps EPIPE? (As in: "the pipe containing events is gone").
Thinking about this some more, -ENOENT is probably what we should
return. *But* when there are no events to dequeue, we should instead
return -EAGAIN (i.e. EWOULDBLOCK) which VIDIOC_DQBUF also uses.
However I'm not sure if anything depends on -ENOENT currently (probably
not really) so changing this might require some consideration. No error
codes are currently defined for VIDIOC_DQEVENT; was planning to fix that
while we're at this.
--
Cheers,
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxx
--
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
