lkml.org 
[lkml]   [2003]   [Dec]   [21]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 21 Dec 2003 07:14:12 -0800 (PST)
FromDavide Libenzi <>
SubjectRe: [RFC,PATCH] use rcu for fasync_lock
On Sun, 21 Dec 2003, Manfred Spraul wrote:

> >What about killing fasync_helper altogether and using the method that
> >epoll uses to register "listeners" which send a signal when the poll
> >state of a device changes?
> >
> I think it would be a step in the wrong direction: poll should go away 
> from a simple wake-up to an interface that transfers the band info 
> (POLL_IN, POLL_OUT, etc). Right now at least two passes over the f_poll 
> functions are necessary, because the info which event actually triggered 
> is lost. kill_fasync transfers the band info, thus I don't want to 
> remove it.

It is my plan to propose (Linus is not contrary, in principle) a change of 
the poll/wake infrastructure for 2.7. There are two areas that can be 
improved. First, f_op->poll() does not allow you to send and event mask, 
and this requires the driver to indiscriminately wake up both IN and OUT 
waiters. The second area will be to give the driver to specify some "info" 
for the wake up. Something like:
wake_up_info(&wq, XXXX);
And add to the wait queue item storage for the passed info. Where "info" 
could be anything from an event mask, up to an allocated object with its 
own destructor. In this way the callback'd waked up will have the "info" 
ready w/out issuing an extra f_op->poll(). The code is pretty much 
trivial, even if changes will touch a bunch of code. The good thing is 
that migration can be gradual, beside the initial dumb compile fixing to 
suite the new f_op->poll() interface.


- Davide


-
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/

\
 
 \ /
  Last update: 2005-03-22 12:59    [from the cache]
©2003-2008