On Fri, 2008-04-11 at 09:40 -0700, bhanu nani wrote:

> code snippet is part of Kernel module.
> 
> > >  Test code:
> > >  --------------
> > >  read()
> > >  {
> > >    if(down_interruptible())
> > >            return error;
> > >    mdelay(10000);
> > >    up();
> > >  }
> > >

> 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.
> 

preemption means that "process a" running kernel code can be interrupted
at more or less any time for some higher priority "process b". when
"process a" eventually runs again it will just pick up where it left
off.

if your code is process a, and is interrupted half-way through mdelay,
when it is recsheduled it will continue to run mdelay. There is nothing
about pre-emption that is going to return control to the terminal prompt
based on a ^C from the tty.







--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ

Reply via email to