今天的两个收获–linux的特性和海森堡式错误

今天我看了一个守护进程的man手册，加深了我对linux的理解，这个守护进程就是netplugd，它主要就是检测网络接口的状态，一旦一个网卡接口接通了，那么就会调用ifup，相反down掉了就会调用ifdown，这里涉及两个问题，第一，用户守护进程netplugd怎么检测到网络接口的状态；第二，用户进程netplug怎么知道检测到接口变化以后要怎么做。对于第一个问题，答案就是netlink套接字，内核肯定知道网络接口的实时状态，一旦知道了状态就会用netlink通知用户空间的netplugd守护进程，内核只管通知，而根本不管用户守护进程会怎么做，从而我们知道内核提供机制，而用户守护进程提供策略，对于第二个问题，答案就是配置文件，当守护进程netplugd接收到netlink的信息后，自己只管接收到而不管具体怎么做，它只是内核机制和真正策略的二传手，真正的策略需要配置文件来定义，它实际上调用了/etc/netplug.d/netplug脚本来执行策略，这里我们知道netplugd守护进程提供机制，而脚本配置文件提供策略。从而我总结出，在linux中，一般的内核机制都会存在一个用户进程，而一个用户进程一般都会有一个配置文件，分层次地体现机制和策略的思想，用户进程作为内核机制的策略和用户配置的机制相当于一个二传手存在。

接下来的第二个收获就是海森堡式错误，这是在内核邮件列表中的一个朋友的回复中学到的，有位朋友问wake_up和printk有什么关系？为什么他调用printk就可以正常执行，而不调用printk内核线程就会锁在那里，我感觉他肯定是在写代码时造成了终端的竞争，因为printk可能要用到终端打印，但是我还是感觉这二者不应该有什么实质性的关系的，后来另一位朋友发言了，这个论点十分精辟，他的回答如下：“海森堡形bug, 来自海森堡测不准原理 当你测试的时候就没有发生相应的bug。因为测试的代码带来一些时间的消耗, 内存/cache的副作用...等待 导致结果正确。50%是跟臆断代码执行的先后关系有关. printk() 仅仅是消耗了一些时间,

使得异步执行的语句的顺序跟你原来编码时臆想的一样, 结果就正确了.”有了这个回答的原文，我就不多说什么了，呵呵，很有趣的。