Click to See Complete Forum and Search --> : Linux signal handler


dennisvr
July 24th, 2002, 03:10 AM
Hi,

I'm writing a kernel module. I want a user program to be able to install a handler for interrupts. Since interrupt handlers must reside in kernel space, I figure this should be done with signals. I allready found a function to send signals (sendsig()), but I can't send any data with it.

Does anyone know of a function to send a signal, with some sort of data? (in aio_read a signal is sent with data, so it should be possible)

Does anyone know of other means to signal a user program that an interrupt occured? I don't want to poll.

Maybe even a complete framework for creating an interrupt handler in user space?

thanx!

Dennis

cup
July 24th, 2002, 04:32 PM
What causes the interrupt? Is it

a) Hardware event - eg Station Alarm
b) Software event - eg Record updated

If it is the latter, there are lots of techniques.

dennisvr
July 25th, 2002, 01:44 PM
it is a hardware interrupt, but does that mean there aren't any options?

cup
July 25th, 2002, 04:06 PM
There probably are options: only it is an area I know nothing about when it comes to Unix. I can tell you all about it in RMX or DOS.

How about this? The program sits on a blocking read on a named port. When the data comes in, it is placed in that port.

dennisvr
July 26th, 2002, 01:34 AM
How about this? The program sits on a blocking read on a named port. When the data comes in, it is placed in that port.
I allready thought about doing an asynchronous (blocking) read, but this would mean a lot of overhead. I would like to prevent that.

cup
July 26th, 2002, 03:35 AM
Another idea - register a circular buffer with the server process. When the data arrives, put it into the buffer and signal the application that there is something there.

You will need the process id to do the signalling anyway so why not register the buffer at the same time.

dennisvr
July 26th, 2002, 06:43 AM
Another idea - register a circular buffer with the server process. When the data arrives, put it into the buffer and signal the application that there is something there.

I'm allready doing that (storing interrupts). Because you can never assume that software is as fast as hardware.

Let me explain a little further.

My driver handles up to 12 modules. So I need to store this for each module. This isn't a problem. When a program install's a signal handler it's pid is stored, and some information about which which interrupt(s) it wants to receive. The driver then handles any incoming interrupts from the modules and sends them to the programs if they wish to receive it. The program receives a signal, but doesn't know anything about this signal, except the signal number. So the program doesn't know what module it came from or what interrupt was given. So if the program would have to poll the driver, the driver would have to check all boards, and find the pid of the program. The program could have more than 1 signal handler installed, and the driver would find 2 (or more) cases of the same board and signal handler combinations. If another interrupt would have been received in the meanwhile (which is possible), there is no way to tell which is the right one.

I hope you understand what I mean. I really think I need to send data with that signal to know what happened.

Thanx,

Dennis

cup
July 26th, 2002, 08:35 AM
Another idea: how about registering a callback which gets called when the signals come in. The callback will save the relevant info and then exit. That way, when the signal is sent, you know the callback would have gotten the latest data and which module it came from.