Hi Philipp,

On Thu, May 10, 2012 at 02:52:11PM +0200, Philipp Ittershagen wrote:

(resend, forgot CC)

Hi Andre!

On Thu, May 10, 2012 at 11:09:07AM +0200, Andre Haupt wrote:

quoted

Hi folks,

Its been a while since i last did some kernel related stuff,
so please bear with me if this sounds strange to your ears.

What i want to achieve:
I want to implement a hardware trigger that a user space process
can react on.

I need a driver that blocks a process/thread until a sepcific
hardware interrupt occurs. The process should call a kernel
interface and then should get blocked until another
process/thread calls another kernel interface to stop waiting
for the irq or an interrupt actually occurs.

What i have:
Back in the days i wrote a little character driver which implemented
2 ioctl commands. One command (IOCTL_TRIGGER_WAIT_IRQ) put the
calling process to sleep using wait_evemt_interruptible() and
the other command (IOCTL_TRIGGER_STOP_WAIT_IRQ) woke a processes
again by calling wake_up_interruptible().

Now ioctls are frowned upon and i do not want to mess with
majors and minors anymore either.

Do you have any hints to the right approach for such a driver?
Should i use some sysfs interface? If yes, which? Or does
such a driver already exist? Can it be one completely in
user space?

Why don't you use open(), write(), read() etc. to do the job?

Tasks which should block can then do 

  echo wait > /dev/yourdevname

and another process can cancel the waiting by doing

  echo cancel > /dev/yourdevname

Or better, reading the device file blocks and returns the trigger status (none,
triggered, aborted) and writing to the device file wakes up the sleeping
processes.

So cat /dev/mydevice would block until an interrupt occurs or someone does
an echo foo > /dev/mydevice.

I vagely remember having done that in the first place. I cant remember
why i went with the ioctl stuff back then, though.

cheers,

Andre