Re: signal handling (clarification needed)

["Talib Alim" <talibalm@hotmail.com>]

> hello talib..
>
> > if (signal_pending)
> >   {
> >    return -EINTER
> >   }
>
> I think this is the problem. You return -EINTR no matter what signal is 
> currently pending. try to study next_signal() in kernel/signal.c, I think 
> by using this function, you can get the signal number of the
> pending signal(s), thus you can act accordingly.
I understand this is the problem, but I do not want to get in the business 
of handling signals in my driver. If I dequeue the signal, than It has to be 
resent (by my driver) when process is goes to user space, what if that 
signal has signal handler ? than I have to run that too.

As I mentioned earlier, accept also does same thing, i.e. it  returns on 
signal_pending true.

My point is what is the correct way of taking care of this situation, i.e. 
driver operating on behave of user process (in kernel context), how should 
suspend signal handled ? if I do not check for signal_pending, than ctrl-c 
will not work, and if e.g. read (or accept) does not get any data 
(connection) than this program will be struck in kernel mode.

I think I am missing some some point, I hope that somebody can help me 
understand this.

Talib Alim

> Since I am not sure if this function is exported, maybe you can use 
> dequeue_signal() instead (also defined in kernel/signal.c).
>
> Good luck...
>
> regards,
>
> Mulyadi

_________________________________________________________________
Don?t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/