On Thursday, July 07, 2011 18:42:55 Jonathan Corbet wrote:
> On Fri, 1 Jul 2011 15:37:30 +0200
> Hans Verkuil <hverk...@xs4all.nl> wrote:
>
> > In some cases the poll() implementation in a driver has to do different
> > things depending on the events the caller wants to poll for. An example is
> > when a driver needs to start a DMA engine if the caller polls for POLLIN,
> > but doesn't want to do that if POLLIN is not requested but instead only
> > POLLOUT or POLLPRI is requested. This is something that can happen in the
> > video4linux subsystem.
>
> The change makes sense to me, FWIW. One bit of trivia I noticed while
> looking at it:
>
> > @@ -796,7 +792,7 @@ static int do_poll(unsigned int nfds, struct poll_list
> > *list,
> > * All waiters have already been registered, so don't provide
> > * a poll_table to them on the next loop iteration.
> > */
> > - pt = NULL;
> > + pt->qproc = NULL;
> > if (!count) {
> > count = wait->error;
> > if (signal_pending(current))
>
> The comment at the beginning of this hunk is no longer accurate since the
> poll_table is, indeed, still being supplied. The previous comment in the
> same function:
>
> /*
> * Fish for events. If we found one, record it
> * and kill the poll_table, so we don't
> * needlessly register any other waiters after
> * this. They'll get immediately deregistered
> * when we break out and return.
> */
>
> Could also use tweaking.
Indeed! I'll make an RFCv3 tomorrow fixing this.
Thanks for looking at this!
Regards,
Hans
--
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
