Hi...
I hope I give you truly correct answer...
On Fri, Apr 11, 2008 at 11:40 PM, bhanu nani <bhanu.lnxnew@xxxxxxxxx> wrote:
> Hi Guys,
>
> I am not sure whether this API is avialable to user space but this
> code snippet is part of Kernel module.
>
>
> > > Test code:
> > > --------------
> > > read()
> > > {
> > > if(down_interruptible())
> > > return error;
> > > mdelay(10000);
> > > up();
> > > }
> > >
> > > With this code in place, I try to do a 'CTRL+C' when it hangs at that delay.
> > > It does not respond to my 'CTRL + C'.
> >
> > Is that user space or kernel space code?
>
> This is my my read implementation of char driver routine i.e. a scull_read.
> With the above code in place, when it hangs in the kernel at mdelay(),
> a 'CTRL+C' does not preempt the kernel process and give back the
> control to terminal prompt.
> The kernel only gives control back after the delay is complete.
> I was thinking CTRL+C should generate a preemption signal to kernel.
> If not, I would like to know what are those signals that can trigger a
> preemption in kernel mode.
OK, I think I know. mdelay() is busy looping, thus your code path
force you to stay in kernel space for that period. Combined with the
fact that signal handler is only meaningful when you go back to user
space, that's why your Ctrl-C doesn't work.
Sorry, suddenly in hurry because my usb flash disk is missing and I
need to find it ASAP
regards,
Mulyadi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
