Em 29-06-2011 02:08, Andy Walls escreveu:
> On Tue, 2011-06-28 at 21:00 -0300, Mauro Carvalho Chehab wrote:
>> Em 28-06-2011 20:14, Andy Walls escreveu:
>>> On Tue, 2011-06-28 at 09:43 -0300, Mauro Carvalho Chehab wrote:
>>>> Em 28-06-2011 09:21, Andy Walls escreveu:
>>>
>>>>> It is also the case that a driver's poll method should never sleep.
>>>>
>>>> True.
>>>
>>>>> One issue is how to start streaming with apps that:
>>>>> - Open /dev/video/ in a nonblocking mode, and
>>>>> - Use the read() method
>>>>>
>>>>> while doing it in a way that is POSIX compliant and doesn't break
>>>>> existing apps.
>>>>
>>>> Well, a first call for poll() may rise a thread that will prepare the
>>>> buffers, and
>>>> return with 0 while there's no data available.
>>>
>>> Sure, but that doesn't solve the problem of an app only select()-ing or
>>> poll()-ing for exception fd's and not starting any IO.
>>
>> Well, a file descriptor can be used only for one thing: or it is a stream
>> file
>> descriptor, or it is an event descriptor. You can't have both for the same
>> file descriptor. If an application need to check for both, the standard Unix
>> way is:
>>
>> fd_set set;
>>
>> FD_ZERO (&set);
>> FD_SET (fd_stream, &set);
>> FD_SET (fd_event, &set);
>>
>> select (FD_SETSIZE, &set, NULL, NULL, &timeout);
>>
>> In other words, or the events nodes need to be different, or an ioctl is
>> needed
>> in order to tell the Kernel that the associated file descriptor will be used
>> for an event, and that vb2 should not bother with it.
>
> Um, no, that is not correct for Unix fd's and socket descriptors in
> general. I realize that v4l2 events need to be enabled with an ioctl(),
> but do we have a restriction that that can't happen on the same fd as
> the one used for streaming?
>
> Back in the days before threads were commonly available on Unix systems,
> a process would use a single thread calling select() to handle I/O on a
> serial port:
>
> fd_set rfds, wfds;
> int ttyfd;
> ...
> FD_ZERO(&rfds);
> FD_SET(ttyfd, &rfds);
> FD_ZERO(&wfds);
> FD_SET(ttyfd, &wfds);
>
> n = select(ttyfd+1, &rfds, &wfds, NULL, NULL);
>
> Or TCP socket
>
> fd_set rfds, wfds, efds;
> int sockd;
> ...
> FD_ZERO(&rfds);
> FD_SET(sockd, &rfds);
> FD_ZERO(&wfds);
> FD_SET(sockd, &wfds);
> FD_ZERO(&efds);
> FD_SET(sockd, &efds);
>
> n = select(sockd+1, &rfds, &wfds, &efds, NULL);
On both serial and socket devices, if select returns a file descriptor,
the data is there or the device/socket got disconnected.
> Waiting for data to arrive on an fd, while not streaming is an error
> condition for select() should return.
Yes, but poll() starts the streaming, if the mmap mode were not started,
according with the V4L2 spec:
http://linuxtv.org/downloads/v4l-dvb-apis/func-poll.html
Thanks,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
