signals handling in the kernel

Mirek23 miroslaw.dach at
Wed Aug 8 18:15:20 EST 2007

Hi Dave,

     I have found the book by Rubini you have mentioned:

I did not find however what would be the best way to propagate interrupt
signals to the USER level / notify the client that interrupt has occurred.

I have checked also in the kernel 2.4 kernel/signal.c file and
kill_proc_info symbol was there exported but in the kernel 2.6 it is not a
case. I have modified the kernel/signal.c file inserting the line:


and I use the kill_proc_info straight from the interrupt handler routine. I
do not know however if it is a safe 
solution. This what does not work with kill_proc_info is that (struct
siginfo *) pInfo->si_value.sival_int
is not passed to the user space. To pass an integer value I use (struct
siginfo *) pInfo->si_code instead.
This works but it is not an elegant solution since the si_code is meant to
be used for something else.

Best Regards


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