interface for a hardware trigger driver

interface for a hardware trigger driver

[Andre Haupt]

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?

puzzled.

cheers,

Andre

interface for a hardware trigger driver

[Philipp Ittershagen]

(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

interface for a hardware trigger driver

[Andre Haupt]

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:
> > 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

interface for a hardware trigger driver

[Philipp Ittershagen]

Hi Andre,

On Thu, May 10, 2012 at 03:18:49PM +0200, Andre Haupt wrote:
> 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.

this is even better, yes.

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

It's always good to drop ioctl code ;) Using the semantics you mentionend
above for read() and write(), the code gets simpler and easier to follow IMHO.


Greetings,

  Philipp

interface for a hardware trigger driver

[richard -rw- weinberger]

On Thu, May 10, 2012 at 11:09 AM, Andre Haupt <andre@bitwigglers.org> wrote:
> 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?
>

You can use UIO.

-- 
Thanks,
//richard