interface for a hardware trigger driver
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
(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
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
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
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
participants (3)
-
Andre Haupt -
Philipp Ittershagen -
richard -rw- weinberger