[go: up one dir, main page]

|
|
Log in / Subscribe / Register

What are they polling for?

By Jonathan Corbet
July 7, 2011
The poll(), select(), and epoll_wait() system calls all allow an application to ask the kernel whether I/O on any of a list of file descriptors would block and, optionally, to wait until one or more descriptors become ready for I/O. Internally, they are all implemented with the poll() method in the file_operations structure:

    unsigned int (*poll) (struct file *filp, struct poll_table_struct *pt);

This function returns a value indicating whether non-blocking I/O is currently possible; it is also expected to add a wait queue to the "poll table" (pt) passed in. If no file descriptors are ready for I/O, the calling process will block on all of the accumulated wait queues.

poll() has long implemented an optimization: if an early poll() function indicates that I/O is possible, the kernel knows that it will not be blocking the calling process. So it stops accumulating wait queues; this state is indicated by passing a null pointer for pt. That all works well except in one case: what if a driver needs access to some of the information stored in the poll table?

In particular, the driver might want to know whether the caller is interested in readiness for read or write access, or whether it is looking for exceptional events. For example, if the application wants to read from the descriptor, the driver may need to fire up some device machinery to make that possible. This situation has not come up very often, but it does tend to affect Video4Linux drivers. In response, Hans Verkuil has posted a patch slightly changing the way poll() works.

With the patch, the poll table is never passed as null; instead, the "we will not be blocking" case is marked internally. So the set of events requested by the application is always available; Hans has provided a helper function to access that information:

    unsigned long poll_requested_events(const poll_table *p);

There has been little discussion of the patch; it doesn't seem like there is any real reason for it not to go in for 3.1.

Index entries for this article
KernelDevice drivers/Support APIs
Kernelpoll()


to post comments


Copyright © 2011, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds