Re: user space device drivers

[jeshkumar555@gmail.com (jeshkumar555@gmail.com)]

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" <gprabhunath@gmail.com>
Date: Tue, May 14, 2013 3:29 pm
Subject: user space device drivers
To: "Gergely Buday" <gbuday@gmail.com>
Cc: "kernelnewbies" <kernelnewbies@kernelnewbies.org>


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 <gbuday@gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/23e69e18/attachment.html