From: Mirek23 <miroslaw.dach@psi.ch>
To: linuxppc-embedded@ozlabs.org
Subject: Re: signals handling in the kernel
Date: Wed, 8 Aug 2007 00:32:42 -0700 (PDT) [thread overview]
Message-ID: <12048448.post@talk.nabble.com> (raw)
In-Reply-To: <46B8BA93.8020909@ovro.caltech.edu>
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.
next prev parent reply other threads:[~2007-08-08 7:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-07 11:32 signals handling in the kernel Mirek23
2007-08-07 16:54 ` David Hawkins
2007-08-07 18:31 ` David Hawkins
2007-08-08 7:32 ` Mirek23 [this message]
2007-08-08 17:19 ` David Hawkins
2007-08-30 15:23 ` Mirek23
2007-08-30 15:57 ` David Hawkins
2007-08-08 8:15 ` Mirek23
2007-08-09 13:47 ` Detlev Zundel
2007-08-20 11:49 ` Mirek23
2007-08-20 16:53 ` David Hawkins
2007-08-23 10:57 ` Mirek23
2007-08-23 16:32 ` David Hawkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12048448.post@talk.nabble.com \
--to=miroslaw.dach@psi.ch \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).