Hello:

I'm trying to understand how the kernel can signal user space with regards to a completion of the kernels event processing based up timer events (timer schedules task on work queue, work queue finishes final processing and needs to alert user space).

Here's the example:

1. User space sends ioctl to kernel. The ioctl is going to activate a timer in the kernel to process something 10 times

2. The kernel processes the ioctl which results in a timer handler to schedule a task on a work queue. This timer fires 10 times say every 30 seconds. So the work queue handler is going to be scheduled to run every 30 seconds (approximately, for the sake of example) over 10 iteration.

3. Upon the 10th timer firing, the schedules yet again the task handing upon the work queue. This final work queue handler completes. It is at this time I want to signal to user space this 10th processing is done. How should I do this?

Another way to ask the question, or a parallel question, is perhaps for an more asynchronous event perspective. Say the kernel has a tone detection algorithm in place and it scans incoming data samples for a certain tone. If the kernel's algorithm detects the tone, it needs to alert some event handler within user space. There is no way to determine if a tone will be detected 5 seconds from now, or 50 days from now. What user space/kernel space scheme should be in place to allow the kernel to notify user space of such an event.

Thanks folks!

Set up a signal handler in the user space process. When all is set up start the kernel code and give it the process ID. When the event happens the kernel sends a signal to the process. The signal handler reads the data from the kernel.

Do you think that the kernel really should be the one doing this, and not just a nice user-land process?

One technique that might be handy is to use the notion of a /proc file ... the userland process simply reads from the file with a blocking read as though it were a pipe. The kernel writes to the file (with some reasonable size-limit in case the userland process is "stuck"), doing so only when it knows that someone's got it open for reading.

Thanks for the input thus far...

>>> Do you think that the kernel really should be the one doing this, and not just a nice user-land process?

I would say 'yes'... what I really have an user space API that sends an ioctl down to the kernel to write to a GPIO device. The GPIO device is connect to LEDs:

User space ---> ioctl ---> Kernel ---> GPIO ----> LED

So that is used to change LED state ('On green', 'On red', 'Off')... one ioctl per LED state change.

Now I want to blink the LED 'On Green'/'Off' 5,000 times. I do not want to make 5,000 ioctl calls into the kernel. Therefore, I send one ioctl to the kernel with my new 'BLINK_CMD' opcode. This in turn activates a kernel timer. When the timer fires, it schedules a task upon a workqueue that will change LED state. The kernel SMBUS API is used, which needs to sleep, and therefore I use this "process context" workqueue technique.

Continuing this example, after the 5,000th kernel timer firing/LED state change, I want to indicate to user space my blink pattern of 5,000 LED changes has completed. I desire some sort of indication from the kernel that the blinking is done. From user space, consider a particular LED "locked" until the current blink processing is done - no other process or application can use that LED. In order to "unlock" the LED, I need the kernel to indicate "I'm done blinking LED #5, so go let someone else else have access to it".

Thoughts?

>>>> One technique that might be handy is to use the notion of a /proc file ... the userland process simply reads from the file with a blocking read as though it were a pipe.

This sounds interesting... could you point me to perhaps a piece of example code?

Thanks again to all!

>>> Set up a signal handler in the user space process. When all is set up start the kernel code and give it the process ID. >>> When the event happens the kernel sends a signal to the process. The signal handler reads the data from the kernel.

Everything I'm discribing needs to be done via a kernel loadable module. I don't (without getting into the "why") have permission to rebuild the entire kernel and add signalling. Can signalling be added via loadable module without rebuilding the entire kernel?

Signals have been built into the kernel since the early sixties for this exact purpose. Its how async I/O works. The call is send_sig.