lkml.org 
[lkml]   [1999]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Async user space notification from kernel?
Date
Nimrod Zimerman [mailto:zimerman@mailandnews.com] wrote:
> On Thu, Aug 26, 1999 at 12:08:20PM -0600, Erik Andersen wrote:
> > Any hints as to what file_ops are needed to support select?
> > Clearly read and write are not sufficient. flush? poll?
>
> From looking at some old code I wrote, what you need to
> change is the poll
> hook, of file_operations. I had some working code who used both this
> approach and a wait-on-read approach, and it works quite fine.
>
> (You actually don't need read() and write() if you don't want
> them. And if
> you want to get data from the device just use read() - you don't
> need select(), unless you wish to enjoy the timeout option).
>
> By the way, why are you calling this an 'async event'? This
> is very much a
> synchronous event. A signal is an asynchronous one.
> Unless I'm missing some terminology here.

I believe the event happens asynchronously to any code. If the app is
supposed to do anything else while waiting, it will be neccessary to spawn a
separate thread in order to wait for the event.

The two approaches remain send a signal or wait (via select(), read() or
ioctl()) for the driver to return.

The tradeoffs I can think of include the following:
1. Latency. Signal may be slightly faster, since I believe that it is
checked first. This depends heavily on how separate threads are scheduled in
Linux.
2. Exact count of events. If you need to know exactly how many times the
event occurred, you need to use one of the other methods. With signal, you
would potentially merge multiple occurances into a single call to the signal
handler. The other methods would allow you to work around this.
3. Efficiency. I have not looked at the code for Linux, but often signal
handling takes more work than waiting on read() or ioctl().
4. poll() gives you a timeout.
5. select() allows you to wait on several different descriptors.

-Bret

-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity

Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------

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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.037 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site