linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Hawkins <dwh@ovro.caltech.edu>
To: Mirek23 <miroslaw.dach@psi.ch>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: signals handling in the kernel
Date: Mon, 20 Aug 2007 09:53:33 -0700	[thread overview]
Message-ID: <46C9C70D.9080903@ovro.caltech.edu> (raw)
In-Reply-To: <12234438.post@talk.nabble.com>

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

  reply	other threads:[~2007-08-20 16:54 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
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 [this message]
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=46C9C70D.9080903@ovro.caltech.edu \
    --to=dwh@ovro.caltech.edu \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=miroslaw.dach@psi.ch \
    /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).