Hi :), One more mechanism I know is passing real time signal to the userspace process using process PID. So whenever there is an interrupt in kernel module, it passes the signal to userspace process. You can handle the signal in US process.
And I passed the PID to kernel module using IOCTL. Let me know if anyone finds problem in handling interrupts like this. Thanks Regards, Jeshwanth Bengaluru ----- Reply message ----- From: "Prabhu nath" <[email protected]> Date: Tue, May 14, 2013 3:29 pm Subject: user space device drivers To: "Gergely Buday" <[email protected]> Cc: "kernelnewbies" <[email protected]> One that I know is through proc interface where the interrupt info is lodged in a file in /proc and the user code keeps polling on this file. Exact use of this is to be looked for. On Tue, May 14, 2013 at 3:24 PM, Gergely Buday <[email protected]> wrote: > Prabhu nath wrote: > > > But if the device has to generate an interrupt on the reception of the > data > > then it is best for the driver code to be in the kernel space waiting for > > the data, rather than in the user space because there is no efficient > > mechanism till now for the control to be transferred to the waiting user > > space code on the reception of the interrupt. > > What are the curently available mechanisms for an interrupt to > propagate into user space? > > Is there one that affects the scheduler? > > - Gergely > -- Regards, Prabhunath G Linux Trainer Bangalore
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
