Re: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em 13-01-2011 01:05, Pawel Osciak escreveu:
> Hi Mauro,
> 
> On Wed, Jan 12, 2011 at 10:49, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote:
>> Em 12-01-2011 08:25, Marek Szyprowski escreveu:
>>> Hello Mauro,
>>>
>>> I've rebased our fimc and saa patches onto http://linuxtv.org/git/mchehab/experimental.git
>>> vb2_test branch.
>>
>> Thanks!
>>
>> As before, I'll be commenting the patches as I'll be seeing any issues.
>>
>>> Pawel Osciak (2):
>>>       Fix mmap() example in the V4L2 API DocBook
>>
>> In fact, the check for retval < 0 instead of retval == -1 is not a fix. According with
>> mmap man pages:
>>        RETURN VALUE
>>               On  success,  mmap() returns a pointer to the mapped area.  On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno
>>               is set appropriately.  On success, munmap() returns 0, on failure -1, and errno is set (probably to EINVAL).
>>
>> The change is not wrong, as -1 is lower than 0, but using -1 is more compliant with
>> libc. So, I'll be applying just the CodingStyle fixes on it.
> 
> Sorry, but I think you got it wrong. The example is called "mmap()
> example". But I did not change return value checking of mmap() calls.
> I changed return value checking of ioctl() calls. So I believe the
> patch is correct.

>From ioctl man page:

RETURN VALUE
       Usually, on success zero is returned.  A few ioctl() requests  use  the
       return  value as an output parameter and return a non-negative value on
       success.  On error, -1 is returned, and errno is set appropriately.

So, at least on glibc, it will return -1 for errors, storing the error code at errno
var, and 0 for OK.

Several V4L2 applications do error checks with -1. So, if some non-glibc implementation
is returning a different return value, that means that several V4L applications will
not work properly. Do you know any case where ioctl is implemented on a different way?

Cheers,
Mauro.
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux