From mboxrd@z Thu Jan  1 00:00:00 1970
From: p.ittershagen@googlemail.com (Philipp Ittershagen)
Date: Thu, 10 May 2012 14:52:11 +0200
Subject: interface for a hardware trigger driver
In-Reply-To: <20120510090907.GA9154@ahauptfedora.berlin.teseq.com>
References: <20120510090907.GA9154@ahauptfedora.berlin.teseq.com>
Message-ID: <20120510125211.GB5622@peter>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

(resend, forgot CC)

Hi Andre!

On Thu, May 10, 2012 at 11:09:07AM +0200, Andre Haupt wrote:
> 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



Greeting,

  Philipp