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

Laurent Pinchart <[email protected]> Tue, 29 Jul 2008 21:05:17 +0200
Newsgroups gmane.comp.video.video4linux,gmane.linux.drivers.spca50x.devel
Message-ID <[email protected]>
On Tuesday 29 July 2008, Mauro Carvalho Chehab wrote:
> On Tue, 29 Jul 2008 00:22:52 +0200
>
> Jiri Slaby <[email protected]> wrote:
> > On 07/29/2008 12:16 AM, Gregor Jasny wrote:
> > > ioctl(3, VIDIOC_REQBUFS or VT_DISALLOCATE, 0x7fffbfda0060) = 2
> > >
> > > Huh? Something evils seems to be going on in V4L2 land.
> > > I've spotted the following lines in videobuf-core.c:videobuf_reqbufs
> > >
> > >         req->count = retval;
> > >
> > >  done:
> > >         mutex_unlock(&q->vb_lock);
> > >         return retval;
> > >
> > > That would explain the retval '2'. It seems a retval = 0; statement is
> > > missing here for the success case.
> >
> > Actually positive ioctl retval used to be often considered as OK in the
> > past (and this approach is still used in few char drivers).
> >
> > But according to v4l docco, it isn't permitted here. Anyway I wouldn't
> > place it in videobuf-core.c, but in vivi code; letting this decision on
> > Mauro (CCed) ;).
>
> This is what videobuf-core do, if success:
>
>         req->count = retval;
>
>  done:
>         mutex_unlock(&q->vb_lock);
>         return retval;
>
> 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.

> IMO, the library patch proposed should be applied. All error checks should
> test for values lower than zero, since positive values don't indicate
> errors.

Best regards,

Laurent Pinchart

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