<div dir="ltr"><div>Greg, then what will you suggest for my case? I mean any alternative ?<br><br></div>Thanks<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 9:55 PM, Greg Kroah-Hartman <span dir="ltr"><<a href="mailto:greg@kroah.com" target="_blank">greg@kroah.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Oct 08, 2014 at 05:57:50PM +0200, Kristof Provost wrote:<br>
> On 2014-10-08 21:14:43 (+0530), Jeshwanth Kumar N K <<a href="mailto:jeshkumar555@gmail.com">jeshkumar555@gmail.com</a>> wrote:<br>
> > Wayback when I was working on some project to wake up userspace program for<br>
> > every rising edge in GPIO pin (hall sensor), I use to send signal to the<br>
> > PID from kernel, before that userspace has to register its PID with kernel<br>
> > module.<br>
> ><br>
> I've seen a certain vendor[1] do something similar. They saved the task<br>
> pointer for whichever process made the magical ioctl() call and used it<br>
> to send signals from the interrupt handler. It worked, right up to the<br>
> point where the process went away and then the kernel panicked.<br>
<br>
</span>Exactly, don't do that :)<br>
<br>
Finding out the real problem that is attempting to be solved would be<br>
good...<br>
<br>
greg k-h<br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Regards<br>Jeshwanth Kumar N K<br></div>Bangalore, India<br></div>
</div>