Re: poll() in 2.6 and beyond

[John Muir]

Richard B. Johnson wrote:

> > Could you maybe go back to the initial report, which is that after
> > poll() gets wrong status? It's nice to argue about where the process
> > waits, but the issue is if it gets the same status with 2.4 and 2.6, 
> and
> > if not which one should be fixed.
> >
> > Richard: can you show this with a small demo program? I assume you
> > didn't find this just by reading code ;-)
>
> 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().
The documentation referred to earlier 
(http://www.xml.com/ldd/chapter/book/ch05.html#t3) clearly states that 
the poll function implementation for a device should:
"1. Call /poll_wait/ on one or more wait queues that could indicate a 
change in the poll status.
2. Return a bit mask describing operations that could be immediately 
performed without blocking."
What happens is if your device has data ready RIGHT NOW (without any 
waiting), the information regarding that is returned.

Now, if you look closely at the implementation of do_poll(), it will 
loop forever until any device returns that data is available (or the 
timeout occurs). After data is available, do_pollfd() function no longer 
adds the devices to the wait queue.

What this means is that the first time through each device is added to 
the wait queue. After the process is woken up from schedule_timeout (or 
the timeout occurs), then it will loop through each device again to 
either add that device to the wait queue again, or determine that there 
is data ready to be read/written, or an error or whatever. do_pollfd() 
then increases count, and do_poll() exits from it's loop (and wait 
queues are cleaned-up in sys_poll()).

So, yes, the poll_wait() returns immediately, it should not wait, and 
your poll method should return the device's CURRENT status in the poll 
mask. Don't worry, because when your device wakes the waiting process 
when data is ready, the device's poll function is called again and you 
again can return the CURRENT status.

Please let me know if I'm misunderstanding this, but quite frankly, 
poll_wait CANNOT wait, for the very reasons described in previous posts: 
when multiple devices are polled, then poll_wait is called FOR EACH DEVICE.

Cheers,

..John


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/