Linux字符设备驱动 异步通知

[枫叶雪]

发现一个不理解的问题啊~
加了fcntl，有的信号的默认响应不能改吗？？

详情如下：
写了一个字符设备的驱动，向外使用kill_fasync(&dev->async-queue, SIGIO, POLL_IN)发送信号，信号也的确送到了上层。在上层我使用signal更改了信号的默认操作，并使用fcntl更改文件的所有者进程为当前进程，并添加异步通知标志，类似如下：
signal(SIGIO, signal_handler);
fcntl(fd, F_SETOWN, getpid());
oflags = fctnl(fd, F_GETFL);
fctnl(fd, F_SETFL, oflags | FASYNC);
应用程序也的确受到了SIGIO，并且执行了signal_handler。
到这里一切正常。。。
但是！
但是！
如果我换了一个信号（不用SIGIO了）比如SIGHUP、SIGRTMIN+1等等，（当然驱动与应用都改）
应用收到信号，却没有执行signal_handler，而是按照默认的响应死掉了！！！（不管是可靠信号，还是不可靠信号，我试了几个，只有SIGIO是正常的执行signal_handler。）
而且！
而且！
如果我的应用不加fcntl的那3行代码，（这就不能得到fd背后那个驱动发出的信号了）于是，使用kill向这个应用发信号（比如kill -s 35 3340），应用都可以获得信号，并执行signal_handler。

字符驱动里发出的信号，只有SIGIO能在应用里改默认相应动作么？？？
这是闹哪样啊~~~~~~~~~~
求解啊~~~~~~~~~~~~~~~
我的系统是 Ubuntu 12.04 内核3.13

[枫叶雪]

我自己顶一下吧。。。 求大神们指导啊~

[枫叶雪]

哎——隔三差五再来顶。。。。。。

[枫叶雪]

驱动开发的论坛里没人知道么。。。 那看看能不能转到应用开发论坛吧。。。

[zuxi]

说一下我的几个看法吧： 1、你看看注册信号处理函数有没有成功； 2、gdb调试，设置signal_handler函数断点，看看有信号时它有没有执行； 3、用SystemTap跟踪一下内核这个函数：get_signal_to_deliver，看看信号处理的流程。 SystemTap是一个比较强大的调试工具，值得花几天学习一下。如果你已经会了的话，可以看看我博客里写的几个SystemTap调试技巧，希望对你有帮助。

[枫叶雪]

引用 4 楼 wangzuxi 的回复:

说一下我的几个看法吧： 1、你看看注册信号处理函数有没有成功； 2、gdb调试，设置signal_handler函数断点，看看有信号时它有没有执行； 3、用SystemTap跟踪一下内核这个函数：get_signal_to_deliver，看看信号处理的流程。 SystemTap是一个比较强大的调试工具，值得花几天学习一下。如果你已经会了的话，可以看看我博客里写的几个SystemTap调试技巧，希望对你有帮助。

谢谢你的帮助~！现在知道问题的原因了。 信号处理函数注册是成功的；但我在用gdb调试那个应用的时候，发现不管我的驱动发出的是什么信号，应用收到的都是SIGIO。而之前，我的操作：将应用和驱动都改为SIGINT（或别的信号）。实际运行时，当驱动发出SIGINT信号的时候，应用收到的实际是SIGIO，应用里只是注册了SIGINT的处理函数，所以当收到SIGIO，进程就死了。 又想到这个问题是因为我在应用加了fcntl的调用，所以man了一下fcntl，有点发现： 使用F_SETFL后，应用收到的信号默认都是SIGIO，（英语不咋地，看起来是这个意思） 那这样就可以解释问题的现象啦~！驱动发出的信号都被改为SIGIO送给了应用，如果应用不处理SIGIO，那它就会死掉。 实际试验一下，的确如此。 又继续研究怎么能让驱动发出啥，应用就收到啥。 根据man说的，是用F_SETSIG。以信号SIGURG为例，我就加了一句： fcntl(fd, F_SETSIG, SIGURG); 发现这个F_SETSIG奇葩啊~~~~~~编译的时候还要额外加编译选项，否则说未定义这个东西： gcc -D_GNU_SOURCE xxx.c 之后我让驱动发SIGURG，应用就能够收到SIGURG了并执行相应的处理函数。问题解决啦~

[zuxi]

引用 5 楼 aningsk 的回复:

[quote=引用 4 楼 wangzuxi 的回复:] 说一下我的几个看法吧： 1、你看看注册信号处理函数有没有成功； 2、gdb调试，设置signal_handler函数断点，看看有信号时它有没有执行； 3、用SystemTap跟踪一下内核这个函数：get_signal_to_deliver，看看信号处理的流程。 SystemTap是一个比较强大的调试工具，值得花几天学习一下。如果你已经会了的话，可以看看我博客里写的几个SystemTap调试技巧，希望对你有帮助。

谢谢你的帮助~！现在知道问题的原因了。 信号处理函数注册是成功的；但我在用gdb调试那个应用的时候，发现不管我的驱动发出的是什么信号，应用收到的都是SIGIO。而之前，我的操作：将应用和驱动都改为SIGINT（或别的信号）。实际运行时，当驱动发出SIGINT信号的时候，应用收到的实际是SIGIO，应用里只是注册了SIGINT的处理函数，所以当收到SIGIO，进程就死了。 又想到这个问题是因为我在应用加了fcntl的调用，所以man了一下fcntl，有点发现： 使用F_SETFL后，应用收到的信号默认都是SIGIO，（英语不咋地，看起来是这个意思） 那这样就可以解释问题的现象啦~！驱动发出的信号都被改为SIGIO送给了应用，如果应用不处理SIGIO，那它就会死掉。 实际试验一下，的确如此。 又继续研究怎么能让驱动发出啥，应用就收到啥。 根据man说的，是用F_SETSIG。以信号SIGURG为例，我就加了一句： fcntl(fd, F_SETSIG, SIGURG); 发现这个F_SETSIG奇葩啊~~~~~~编译的时候还要额外加编译选项，否则说未定义这个东西： gcc -D_GNU_SOURCE xxx.c 之后我让驱动发SIGURG，应用就能够收到SIGURG了并执行相应的处理函数。问题解决啦~ [/quote] 只要是问题肯定是有解决办法的，一些问题别只看表象，要深入去看问题产生的根本原因，怀疑是哪一块的问题就去看它的源码，不管是自己的程序，还是glibc、bash，甚至内核，反正这些都能找到源码。再就是适当借助调试工具，提高debug效率。

[枫叶雪]

引用 6 楼 wangzuxi 的回复:

[quote=引用 5 楼 aningsk 的回复:] [quote=引用 4 楼 wangzuxi 的回复:] 说一下我的几个看法吧： 1、你看看注册信号处理函数有没有成功； 2、gdb调试，设置signal_handler函数断点，看看有信号时它有没有执行； 3、用SystemTap跟踪一下内核这个函数：get_signal_to_deliver，看看信号处理的流程。 SystemTap是一个比较强大的调试工具，值得花几天学习一下。如果你已经会了的话，可以看看我博客里写的几个SystemTap调试技巧，希望对你有帮助。

谢谢你的帮助~！现在知道问题的原因了。 信号处理函数注册是成功的；但我在用gdb调试那个应用的时候，发现不管我的驱动发出的是什么信号，应用收到的都是SIGIO。而之前，我的操作：将应用和驱动都改为SIGINT（或别的信号）。实际运行时，当驱动发出SIGINT信号的时候，应用收到的实际是SIGIO，应用里只是注册了SIGINT的处理函数，所以当收到SIGIO，进程就死了。 又想到这个问题是因为我在应用加了fcntl的调用，所以man了一下fcntl，有点发现： 使用F_SETFL后，应用收到的信号默认都是SIGIO，（英语不咋地，看起来是这个意思） 那这样就可以解释问题的现象啦~！驱动发出的信号都被改为SIGIO送给了应用，如果应用不处理SIGIO，那它就会死掉。 实际试验一下，的确如此。 又继续研究怎么能让驱动发出啥，应用就收到啥。 根据man说的，是用F_SETSIG。以信号SIGURG为例，我就加了一句： fcntl(fd, F_SETSIG, SIGURG); 发现这个F_SETSIG奇葩啊~~~~~~编译的时候还要额外加编译选项，否则说未定义这个东西： gcc -D_GNU_SOURCE xxx.c 之后我让驱动发SIGURG，应用就能够收到SIGURG了并执行相应的处理函数。问题解决啦~ [/quote] 只要是问题肯定是有解决办法的，一些问题别只看表象，要深入去看问题产生的根本原因，怀疑是哪一块的问题就去看它的源码，不管是自己的程序，还是glibc、bash，甚至内核，反正这些都能找到源码。再就是适当借助调试工具，提高debug效率。[/quote] 是啊~是啊~要不是gdb，我也就不知道应用收到的总是SIGIO啦~~~ 源码、工具很重要呐~~~ 嘿嘿，谢谢

[dragon_cdut]

楼主能贴一下应用层代码吗？我按照你的方法--fcntl(fd, F_SETSIG, SIGURG);还是不行。

[dragon_cdut]

引用 9 楼 renlonggg 的回复:

楼主能贴一下应用层代码吗？我按照你的方法--fcntl(fd, F_SETSIG, SIGURG);还是不行。

现在可以了，忘记写signal（）函数了,复制粘贴时少复制了这个函数