Messages in this thread | | | Subject | Re: poll() in 2.6 and beyond | From | David Dillow <> | Date | 02 Mar 2004 22:57:01 -0500 |
| |
On Tue, 2004-03-02 at 18:32, Richard B. Johnson wrote: > Yes. The code I attached earlier shows that the poll() in a driver > gets called (correctly), then it calls poll_wait(). Unfortunately > the call to poll_wait() returns immediately so that the return > value from the driver's poll() is whatever it was before some > event occurred that the driver was going to signal with > wake_up_interruptible().
You've been handed a clue enough times now that you should understand that poll_wait() does not, and has never, put the process to sleep.
If you can show a case where do_poll() returns stale data, then by all means do so. We will be happy to fix any such error in the kernel.
You say do_poll() looses the status returned from your driver's poll method. If your driver is truly returning a nonzero status from the poll() method call, then a simple read of the code in do_pollfd() will show that the only way it looses information from that event mask is if your user space is not setting that event type in pollfd.events.
If I were you, I'd check two things: 1) that your poll method is really returning a non-zero status when you think it is 2) that your user space program is really asking for all events you think it is
I think you'll find your problem is not this well-used mechanism in the kernel.
Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |