|
-
July 24th, 2002, 03:10 AM
#1
Linux signal handler
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
-
July 24th, 2002, 04:32 PM
#2
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.
Succinct is verbose for terse
-
July 25th, 2002, 01:44 PM
#3
it is a hardware interrupt, but does that mean there aren't any options?
-
July 25th, 2002, 04:06 PM
#4
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.
Succinct is verbose for terse
-
July 26th, 2002, 01:34 AM
#5
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.
-
July 26th, 2002, 03:35 AM
#6
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.
Succinct is verbose for terse
-
July 26th, 2002, 06:43 AM
#7
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
-
July 26th, 2002, 08:35 AM
#8
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.
Succinct is verbose for terse
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|