signals handling in the kernel

signals handling in the kernel

[Mirek23]

Hi All,

    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.

When I have compiled my module which uses the kill_proc_info I have got and
error messge:

WARNING: "kill_proc_info" [drivers/char/xilinx_gpio/xilinx_gpio.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

The  kill_proc_info source code is in the kernel/signal.c file. Due to
unknown reason the kill_proc_info symbol is not exported with EXPORT_SYMBOL
entry.


I can modify the file kernel/signal.c adding the line
EXPORT_SYMBOL(kill_proc_info) but maybe it is a good reason in order not to
use this function straight. If so what would be the best way to send a
signal form the kernel interrupt handler routine to the user space together
with the siginfo data.

Best Regards

Mirek
   
-- 
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12032525
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: signals handling in the kernel

[David Hawkins]

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.

Cheers
Dave

Re: signals handling in the kernel

[David Hawkins]

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

Re: signals handling in the kernel

[Mirek23]

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
device.

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 

Mirek 




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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12048448
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: signals handling in the kernel

[David Hawkins]

Hi Mirek,

> 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 device.
> 
> 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.

Signals are not the appropriate solution.

It sounds like your application is read-only, so how about
the following use-cases for the driver:

1. In user-space, you only have one GPIO, and the code
    only needs to react in response to this one I/O port.
    The information required by user-space is the 1-byte
    (or 2, or 4) of GPIO

    Solution:
    The driver implements a buffer that a user-space read() call
    consumes. A user-space read() call blocks until there is
    data in the buffer.

    The driver ISR reads the GPIO port, and writes the
    contents to the buffer.

2. In user-space, you have multiple GPIO ports, and
    the code needs to respond to any one.

    Solution:
    The driver implements the poll() call back so that
    user-space can call select() on the multiple GPIO
    file descriptors.

    Again, the driver ISR reads the different GPIO ports,
    and writes the data to the GPIO specific buffer.

I have plenty of driver code lying around, and can point
you to an example that implements both of these options.
The driver easily supports both (1) and (2) since
(1) is just a blocking-read, and (2) is poll().

Is the kernel 2.4 or 2.6? Here's some code I wrote for
2.6, and this code was ported from some 2.4 drivers
(and I still have that code in CVS)

http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-762-Hawkins.pdf

I can re-write say the parallel port example to demonstrate
how the value of the GPIO port (the parallel port) can be
sent to user space. There's a parallel port interrupt
example in there somewhere. I know I wrote a GPIO driver
for my Yosemite board (440EP example), but I don't see it
in that zip ... it must be lying around here somewhere :)

I wouldn't necessarily copy say a parallel port example
verbatim, since there is only ever one of those devices
in a system. There are more likely to be multiple GPIO ports,
so the driver design would be generalized a little more.
Look at the COBRA driver code. I have crates of cPCI equipment
loaded with 10s of boards, with each board having multiple
device nodes, transferring megabytes per second over
multiple cPCI crates :)

Anyway, stop thinking about signals, they'll just mess you up.

Oh, the driver will also support sending SIGIO to the process,
via the fasync() driver call, so you can try signals, and
convince yourself that select() is much nicer.

A GPIO driver seems like such an obvious thing to write. Are
you sure the montavista driver doesn't already support these
features? I have no idea of your experience with coding, so
it could just be that you are unaware of what the driver
implements. If you are allowed to post it, go ahead, and
I'll comment on its features.

Cheers
Dave

Re: signals handling in the kernel

[Mirek23]

Hi David,

       I went throught the Rubini book about device drivers and I see that
you are absolutly right about
the way how to handle interrupts in the user space. 

When I find a bit of time I will try your first suggestion with read() which
bolckes in the user space and
waits forr ISR to write data to the buffer.

Many thanks for all your suggestions

Best Regards

Mirek




David Hawkins-3 wrote:
> 
> Hi Mirek,
> 
>> 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 device.
>> 
>> 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.
> 
> Signals are not the appropriate solution.
> 
> It sounds like your application is read-only, so how about
> the following use-cases for the driver:
> 
> 1. In user-space, you only have one GPIO, and the code
>     only needs to react in response to this one I/O port.
>     The information required by user-space is the 1-byte
>     (or 2, or 4) of GPIO
> 
>     Solution:
>     The driver implements a buffer that a user-space read() call
>     consumes. A user-space read() call blocks until there is
>     data in the buffer.
> 
>     The driver ISR reads the GPIO port, and writes the
>     contents to the buffer.
> 
> 2. In user-space, you have multiple GPIO ports, and
>     the code needs to respond to any one.
> 
>     Solution:
>     The driver implements the poll() call back so that
>     user-space can call select() on the multiple GPIO
>     file descriptors.
> 
>     Again, the driver ISR reads the different GPIO ports,
>     and writes the data to the GPIO specific buffer.
> 
> I have plenty of driver code lying around, and can point
> you to an example that implements both of these options.
> The driver easily supports both (1) and (2) since
> (1) is just a blocking-read, and (2) is poll().
> 
> Is the kernel 2.4 or 2.6? Here's some code I wrote for
> 2.6, and this code was ported from some 2.4 drivers
> (and I still have that code in CVS)
> 
> http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
> http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
> http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-762-Hawkins.pdf
> 
> I can re-write say the parallel port example to demonstrate
> how the value of the GPIO port (the parallel port) can be
> sent to user space. There's a parallel port interrupt
> example in there somewhere. I know I wrote a GPIO driver
> for my Yosemite board (440EP example), but I don't see it
> in that zip ... it must be lying around here somewhere :)
> 
> I wouldn't necessarily copy say a parallel port example
> verbatim, since there is only ever one of those devices
> in a system. There are more likely to be multiple GPIO ports,
> so the driver design would be generalized a little more.
> Look at the COBRA driver code. I have crates of cPCI equipment
> loaded with 10s of boards, with each board having multiple
> device nodes, transferring megabytes per second over
> multiple cPCI crates :)
> 
> Anyway, stop thinking about signals, they'll just mess you up.
> 
> Oh, the driver will also support sending SIGIO to the process,
> via the fasync() driver call, so you can try signals, and
> convince yourself that select() is much nicer.
> 
> A GPIO driver seems like such an obvious thing to write. Are
> you sure the montavista driver doesn't already support these
> features? I have no idea of your experience with coding, so
> it could just be that you are unaware of what the driver
> implements. If you are allowed to post it, go ahead, and
> I'll comment on its features.
> 
> Cheers
> Dave
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12409543
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: signals handling in the kernel

[David Hawkins]

Hi Mirek,

> I went throught the Rubini book about device drivers
> and I see that you are absolutly right about
> the way how to handle interrupts in the user space. 

Great, glad to hear you are convinced :)

> When I find a bit of time I will try your first
> suggestion with read() which blocks in the user space
> and waits for ISR to write data to the buffer.

Look at the example drivers I wrote. Its all in
there, just copy whatever you want.

> Many thanks for all your suggestions

No problem! Its the open-source way ;)

Cheers,
Dave

Re: signals handling in the kernel

[Mirek23]

Hi Dave,

     I have found the book by Rubini you have mentioned:
http://www.oreilly.com/catalog/linuxdrive3/book/index.csp

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:

EXPORT_SYMBOL(kill_proc_info);

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

Mirek


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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12048974
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: signals handling in the kernel

[Detlev Zundel]

Hi Miroslaw,

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

Follow the advice given here before (and in the book you mention), and
implement poll() in the driver and use select() from userspace to
react to it.  That's the natural solution in the Unix context for what
you are trying to do.  It is not a coincidence that I can only find 3
references to kill_proc below drivers/.

Of course you are welcome to solve your actual problem (using
kill_proc like e.g. drivers/char/watchdog/wd.c) but I am very sure
that you will rediscover the information in the preceding paragraph
the hard way.

Bets wishes
  Detlev

-- 
You get 3 opportunities to advertise your Rock band, no more.
           -- Proposed Symbolics guidelines for mail messages (1984)
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de

Re: signals handling in the kernel

[Mirek23]

Thank you for you suggestions. Sorry for the dealy but I was on holidays.

I understand that select() is more appropriate solution to handle
interrupts.
In my case I found somehow more convenient to deal with signals. The server
program which I use was originally written for VxWorks. In VxWorks there was
no separation betwenn the user and kernel space. When the interrupt occured
in VxWorks the interrupt service routine was called. The interrupt service
routine was implemented in the server. 

I found it somehow easier to use signals to trigger signal handler
(previously in VxWorks interrupt service routine) than changing the
structure of the server to deal with select().

I hope however that there is no fundamental problem with sending signals
from kernel (interrupt service routine) to the user space.
I do not know why the function kill_proc_info does not export its symbol
within the kernel 2.6.21 .
With previous version of the kernel 2.4 and early 2.6.* the kill_proc_info
symbol was exported.

Best Regards

Mirek  

    

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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12234438
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: signals handling in the kernel

[David Hawkins]

Hi Mirek,

> In my case I found somehow more convenient to deal with
> signals.

Ok.

> The server program which I use was originally written
> for VxWorks. In VxWorks there was no separation betwenn
> the user and kernel space. When the interrupt occured
> in VxWorks the interrupt service routine was called.
> The interrupt service routine was implemented in the server. 
> 
> I found it somehow easier to use signals to trigger signal handler
> (previously in VxWorks interrupt service routine) than changing the
> structure of the server to deal with select().

I guess it depends on what you consider 'easier'.
Signals have potential race conditions, and so using
select() is safer. I find it 'easier' to have less
problems, so would spend the time to make the server
use select().

But, you are free to ignore this advice. :)

> I hope however that there is no fundamental problem with
> sending signals from kernel (interrupt service routine)
> to the user space.

There are potential race conditions. I'm not sure if this
problem was 2.4 kernel specific, or 2.6 kernel specific,
or signals specific. I think its signals specific.

A web search should yield more info on this. Try googling
'signals race condition', and it looks like its a problem
still.

So it depends on whether your server is running in
a critical, and secure system, as to whether you want
to stick with signals.

> I do not know why the function kill_proc_info does not 
> export its symbol within the kernel 2.6.21 .
> With previous version of the kernel 2.4 and early 2.6.*
> the kill_proc_info symbol was exported.

If SIGIO is sufficient for you, then just use the driver
fasync() call-back mechanism. The example code I referred
to has an example. If its not clear to you, I can
explain it.

If you're having to modify some corner of the kernel not
used by many, then I'm sure your solution is not the
correct one, and you won't get anyone helping you
when things go wrong.

So, take the experience of others; re-write the server
to use signals. If the server was well written to start
with you should be able to call the 'signal handler'
function after returning from your select() call with
the handle ready. It shouldn't be that hard.

Come on, you've just returned from holiday, it should
be no sweat to code up a new server :)

Regards,
Dave

Re: signals handling in the kernel

[Mirek23]

Hi David,

    Thank you for your hints. I was not aware about race conditions in
signal handling routines. So far I did not noticed any anomalies when
running my server since I use only one interrupt which refers to only one
signal. 
I would be interested however in the solution you have suggested with:
SIGIO and fasync() 

Would you be so kind to provide me with some example code.

Best Regards

Mirek




David Hawkins-3 wrote:
> 
> Hi Mirek,
> 
>> In my case I found somehow more convenient to deal with
>> signals.
> 
> Ok.
> 
>> The server program which I use was originally written
>> for VxWorks. In VxWorks there was no separation betwenn
>> the user and kernel space. When the interrupt occured
>> in VxWorks the interrupt service routine was called.
>> The interrupt service routine was implemented in the server. 
>> 
>> I found it somehow easier to use signals to trigger signal handler
>> (previously in VxWorks interrupt service routine) than changing the
>> structure of the server to deal with select().
> 
> I guess it depends on what you consider 'easier'.
> Signals have potential race conditions, and so using
> select() is safer. I find it 'easier' to have less
> problems, so would spend the time to make the server
> use select().
> 
> But, you are free to ignore this advice. :)
> 
>> I hope however that there is no fundamental problem with
>> sending signals from kernel (interrupt service routine)
>> to the user space.
> 
> There are potential race conditions. I'm not sure if this
> problem was 2.4 kernel specific, or 2.6 kernel specific,
> or signals specific. I think its signals specific.
> 
> A web search should yield more info on this. Try googling
> 'signals race condition', and it looks like its a problem
> still.
> 
> So it depends on whether your server is running in
> a critical, and secure system, as to whether you want
> to stick with signals.
> 
>> I do not know why the function kill_proc_info does not 
>> export its symbol within the kernel 2.6.21 .
>> With previous version of the kernel 2.4 and early 2.6.*
>> the kill_proc_info symbol was exported.
> 
> If SIGIO is sufficient for you, then just use the driver
> fasync() call-back mechanism. The example code I referred
> to has an example. If its not clear to you, I can
> explain it.
> 
> If you're having to modify some corner of the kernel not
> used by many, then I'm sure your solution is not the
> correct one, and you won't get anyone helping you
> when things go wrong.
> 
> So, take the experience of others; re-write the server
> to use signals. If the server was well written to start
> with you should be able to call the 'signal handler'
> function after returning from your select() call with
> the handle ready. It shouldn't be that hard.
> 
> Come on, you've just returned from holiday, it should
> be no sweat to code up a new server :)
> 
> Regards,
> Dave
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12291367
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: signals handling in the kernel

[David Hawkins]

Hi Mirek,

> Thank you for your hints. I was not aware about race
> conditions in signal handling routines. So far I did
> not noticed any anomalies when running my server
> since I use only one interrupt which refers to only one
> signal. I would be interested however in the solution
> you have suggested with: SIGIO and fasync() 
> 
> Would you be so kind to provide me with some example code.

Look at simple_driver.c and simple_driver_test.c in

http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html

Note that I used the old signals API in the user-space test:

    /* Connect up the signal handler */
    signal(SIGIO, &sigio_handler);

But you should really use the new signals API. I can't
remember the reason, it'll be explained in the Robbins&Robbins
book I reference below.

Note that another issue with signals is that they are
not queued. So if you have multiple events, you might
miss one.

I found a reference to unreliable signals. Take a look
at the signals chapter in "Advanced Programming in the Unix
Environment", by Stevens. However, that book is a bit old
now. The lack of safety may now only apply to that specific
signals API.

Another nice book is "Unix Systems Programming", by Robbins
and Robbins. Look in Chapter 8. Especially Section 8.6. That
section discusses the problems you'll face when your signal
interrupts POSIX calls, and functions that are signal handler
safe.

These types of issues would not be faced using select().
Hence the reason I can't remember the details on using
signals; as I rarely use them. The exception is that I
do catch ctrl-C to then shut down a process cleanly.
However, most of my user-space code is written using the
ACE C++ classes and infra-structure, and in that case you
deal with signals by creating an event handler, and
registering it with a reactor, which is implemented with,
you guessed it, select().  Notice the theme ... :)

The ACE C++ libraries are detailed in: "C++ Network
Programming" Volume 1 & 2 by Huston and Schmidt, and
in "The ACE programmers guide", by Huston et al.

Cheers,
Dave