On Wed, Jan 10, 2018 at 04:58:24PM +0100, Christoph Hellwig wrote:
> ->get_poll_head returns the waitqueue that the poll operation is going
> to sleep on. Note that this means we can only use a single waitqueue
> for the poll, unlike some current drivers that use two waitqueues for
> different events. But now that we have keyed wakeups and heavily use
> those for poll there aren't that many good reason left to keep the
> multiple waitqueues, and if there are any ->poll is still around, the
> driver just won't support aio poll.
There's another problem with that - currently ->poll() may tell you "sod off,
I've got nothing for you to sleep on, eat your POLLHUP|POLLERR|something
and don't pester me again". With your API that's hard to express sanely.
Another piece of fun related to that is handling of disconnects in general -
static __poll_t proc_reg_poll(struct file *file, struct poll_table_struct *pts)
{
struct proc_dir_entry *pde = PDE(file_inode(file));
__poll_t rv = DEFAULT_POLLMASK;
__poll_t (*poll)(struct file *, struct poll_table_struct *);
if (use_pde(pde)) {
poll = pde->proc_fops->poll;
if (poll)
rv = poll(file, pts);
unuse_pde(pde);
}
return rv;
}
and similar in sysfs.
Note, BTW, the places like wait->_qproc = NULL; in do_select() and its ilk.
Some of them are "don't bother putting me on any queues, I won't be sleeping
anyway". Some are "I'm already on all queues I care about, I'm going to
sleep now and the query everything again once woken up". It would be nice
to have the method splitup reflect that kind of logics...
What about af_alg_poll(), BTW? Looks like you've missed that one...
Another thing: IMO file_can_poll() should use FMODE_CAN_POLL - either as
"true if set, otherwise check ->f_op and set accordingly" or set in
do_dentry_open() and just check it in file_can_poll()...
