On Thu, Jan 11, 2018 at 05:47:50PM +, Al Viro wrote:
> What I mean is that it would be nice to have do_select() and friends aware of
> that.
> You are hiding the whole thing behind vfs_poll(); sure, we can't really
> exploit
> that while we have the mix of converted and unconverted
On Thu, Jan 11, 2018 at 05:47:50PM +, Al Viro wrote:
> Besides having two queues, note the one-time sync_serial_start_port()
> there. Where would you map such things? First ->poll_mask()?
->get_poll_mask. These sorts of calls are the prime reason why
the events argument is passed to it.
>
On Thu, Jan 11, 2018 at 12:36:00PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 09:04:16PM +, Al Viro wrote:
> > 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
On Wed, Jan 10, 2018 at 09:04:16PM +, Al Viro wrote:
> 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.
And what
For other horrors that are even worse than any given ->poll instance
take a look at scif_poll and friends..
On Thu, Jan 11, 2018 at 05:22:00AM +, Al Viro wrote:
> Whee... The very first ->poll() instance in alphabetic order on pathnames:
> in arch/cris/arch-v10/drivers/gpio.c
>
> static __poll_t gpio_poll(struct file *file, poll_table *wait)
> {
> __poll_t mask = 0;
> struct
On Wed, Jan 10, 2018 at 09:04:16PM +, Al Viro wrote:
> 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,
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
->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