Subject: Re: signals handling in the kernel

From: David Hawkins <[email-masked]>
Date: Mon, 20 Aug 2007 09:53:33 -0700

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