Re: [V4l2-library] Messed up syscall return value

On Tuesday 29 July 2008, Mauro Carvalho Chehab wrote:
> On Tue, 29 Jul 2008 21:05:17 +0200
>
> Laurent Pinchart <[email protected]> wrote:
> > > So, it returns the number of buffers that were really allocated. It is
> > > too late to change this, since this behaviour is very old. If the V4L2
> > > API spec is different, we should fix at the spec, not at the driver.
> >
> > I'm not sure to agree with that. The spec clearly states that 0 is
> > returned on success and -1 on error. Since applications don't choke with
> > the currently buggy videobuf-core implementation, they must all be check
> > against -1, or checking for a negative error code. So returning 0
> > shouldn't break any application, except if it relies on the ioctl
> > returning the number of buffers, which is not documented anywhere.
>
> There are some apps that relies on the number of buffers allocated. This is
> important on some cases. For example, if you have digital audio support,
> userspace app needs to know how much buffers were allocated, in order to
> proper synchronize audio and video.
>
> In the case of videobuf, used by most drivers since pre-2.6 kernels, it
> returns it at both req->count and as the returned value for ioctl.
>
> So, userspace apps may use req->count to know the effective number of
> allocated buffers, or the returned value for the ioctl. Since most apps
> were done considering bttv (a client of videobuf), I don't doubt that some
> of them are just using the returned value at the ioctl.

The documentation clearly states that the ioctl returns 0 on success, not the 
number of allocated buffers. Applications that have been developed from the 
spec will not break. Applications that rely on the wrong return value have 
been developed in violation of the spec.

This situation is analogous to using a structure with a reserved field that is 
clearly marked as "don't touch" by the spec. If an application relies on the 
reserved field being set to a specific value, you will surely not refrain 
from changing that value in the kernel because it would break the 
application.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list