signals handling in the kernel

Mirek23 miroslaw.dach at
Wed Aug 8 17:32:42 EST 2007

Hi Dave,

       I run embedded Linux on ppc405 (ml403 xilinx evaluation board). I use
the GPIO based device build on FPGA part of the xilinx chip.  My gpio device
generates interrupts whenever it changes its state.
I use Montavista gpio driver with some modifications to react on interrupts.
Each time when interrupt occurs the interrupt handler routine is called.
This routine sends the signal to the application in user space to trigger
it. When the application is triggered it reads the data from the GPIO

I read that in this situation the best is to use signals. In my case the
ideal would be to use kill_proc_info which sends to the application the
Signal with info data were I intended to put just one integer value. Such a
value determines how to react for the signal on the application level.

Would you have some other suggestion better then the kill_proc_info function
use or even different technique then signaling.

Could you please direct me to the Rubini documentation which you have
mentioned in your last post.

Many thanks 


David Hawkins-3 wrote:
> Hi Mirek,
>>>     I would like to send signals from the interrupt handler
>>> routine (in the kernel) to the user application (in user space).
>>> I have googled on that net and I have found that it could be done with
>>> the
>>> function: kill_proc_info.
>> Look in Rubini for the section regarding asynchronous
>> notification, Ch 6.
>> The callback to generate SIGIO is fasync.
> Actually, before you go off and implement something, can
> you describe why you want to use signals.
> I mistakenly used signals once to indicate notification of
> an event. Then when I wanted multiple events from multiple
> boards I found the problem with signals; you don't know
> who sent it.
> Using select() on multiple file descriptors ended up being
> a more appropriate solution for my application. That
> solution also works nicely with the ACE C++ ACE_Reactor
> pattern.
> Cheers,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at

View this message in context:
Sent from the linuxppc-embedded mailing list archive at

More information about the Linuxppc-embedded mailing list