Vijay Ram Chitrapu (RCVIJAYD) wrote:
hi
as i have already mentioned in a mail the scenario where i would need to
asynchronously notify from kernel to user, i have taken a stand of sending
a signal SIGIO to one process and any unsed signal to the other process.
Can anyone tell me if it is possible to send any signals through
kill_fasync. most drivers in linux source code which i have come across
used only SIGIO for this kind of notification..i am not very much sure if
signals like SIGUSR1 or SIGUSR2 can also be used ? I am sure SIGUSR1 or
SIGUSR2 are not used anywhere.
can anyone plz clear this doubt ??
thanks in advance
you sound *commited* to signals, in the face of the advice given in this
thread.
So I quote:
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
If this is a real-life project, chances are real that someone will add
requirements later
that are unworkable in the then-legacy signals implementation.
Someone will toss your work, cursing while they do.
With any luck, that someone will be you, and it wont get back to your boss.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
