Re: signal handling (clarification needed)
From: Talib Alim
Date: Mon May 22 2006 - 02:05:46 EST
hello talib..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.
> 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.
As I mentioned earlier, accept also does same thing, i.e. it returns on
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
Since I am not sure if this function is exported, maybe you can use
dequeue_signal() instead (also defined in kernel/signal.c).
Don?t just search. Find. Check out the new MSN Search!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/