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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
