Linux本身是一个发展中的操作系统。它有很多前期不完善的机制，被后代用*的机制代替。但是老的机制不可能一下子就消亡，因此由于“历史原因”，会产生很多*旧机制共存的情况。而且Linux的教科书数不胜数，那些老的经典教科书的某些章节其实在技术上已经有点过时。这实际上为我们初学者带来了麻烦：一方面，我们要同时掌握*旧两种机制；另一方面，拿设备驱动的使用来说，*旧设备驱动的使用方式也不同，这在初学时会带来一些困扰。因此在学习时，不要抱住所谓“经典”的教科书不放，多看看外面的世界会比较好。如果要举一个例子来佐证的话，我就会举 sys 文件系统的例子：
“sysfs 本身并不是一项很*的技术，但笔者发现，虽然 sysfs 从2003年诞生至今已有5年，但人们对 sysfs 依然缺乏了解；一个很重要的原因可能是缺乏文档， Linux 内核方面最重要的理论书籍“Linux 设备驱动第3版”和“理解 Linux 内核第2版”都诞生于2003年前后，并且从那以后尚未有再版过，其它一些重要文章则多对 sysfs 与 proc 相提并论且举例常常只有 proc，这导致了 sysfs 的很多重要概念至今仍鲜为人知。”
“sysfs 给应用程序提供了统一访问设备的接口，但可以看到， sysfs 仅仅是提供了一个可以统一访问设备的框架，但究竟是否支持 sysfs 还需要各设备驱动程序的编程支持；在 2.6 内核诞生 5年以来的发展中，很多子系统、设备驱动程序逐渐转向了 sysfs 作为与用户空间友好的接口，但仍然也存在大量的代码还在使用旧的 proc 或虚拟字符设备的 ioctl 方式；如果仅从最终用户的角度来说， sysfs 与 proc 都是在提供相同或类似的功能，对于旧的 proc 代码，没有绝对的必要去做 proc 至 sysfs 的升级；因此在可预见的将来， sysfs 会与 proc, debugfs, configfs 等共存很长一段时间。”——www.ibm.com/developerworks/cn/linux/l-cn-sysfs/
另外，各种设备驱动也是很多不同的人在不同时间写的，尽管linux规定了一些框架规则，但使用方式在细节上难免有差别，因此只有多阅读源码或说明文档才能解决问题。我们在编写自己的应用程序和驱动程序时，也要尽可能遵照最*标准来写，这样方便与别人交流和共享。
Linux本身是一个发展中的操作系统。它有很多前期不完善的机制，被后代用*的机制代替。但是老的机制不可能一下子就消亡，因此由于“历史原因”，会产生很多*旧机制共存的情况。而且Linux的教科书数不胜数，那些老的经典教科书的某些章节其实在技术上已经有点过时。这实际上为我们初学者带来了麻烦：一方面，我们要同时掌握*旧两种机制；另一方面，拿设备驱动的使用来说，*旧设备驱动的使用方式也不同，这在初学时会带来一些困扰。因此在学习时，不要抱住所谓“经典”的教科书不放，多看看外面的世界会比较好。如果要举一个例子来佐证的话，我就会举 sys 文件系统的例子：
“sysfs 本身并不是一项很*的技术，但笔者发现，虽然 sysfs 从2003年诞生至今已有5年，但人们对 sysfs 依然缺乏了解；一个很重要的原因可能是缺乏文档， Linux 内核方面最重要的理论书籍“Linux 设备驱动第3版”和“理解 Linux 内核第2版”都诞生于2003年前后，并且从那以后尚未有再版过，其它一些重要文章则多对 sysfs 与 proc 相提并论且举例常常只有 proc，这导致了 sysfs 的很多重要概念至今仍鲜为人知。”
“sysfs 给应用程序提供了统一访问设备的接口，但可以看到， sysfs 仅仅是提供了一个可以统一访问设备的框架，但究竟是否支持 sysfs 还需要各设备驱动程序的编程支持；在 2.6 内核诞生 5年以来的发展中，很多子系统、设备驱动程序逐渐转向了 sysfs 作为与用户空间友好的接口，但仍然也存在大量的代码还在使用旧的 proc 或虚拟字符设备的 ioctl 方式；如果仅从最终用户的角度来说， sysfs 与 proc 都是在提供相同或类似的功能，对于旧的 proc 代码，没有绝对的必要去做 proc 至 sysfs 的升级；因此在可预见的将来， sysfs 会与 proc, debugfs, configfs 等共存很长一段时间。”——www.ibm.com/developerworks/cn/linux/l-cn-sysfs/
另外，各种设备驱动也是很多不同的人在不同时间写的，尽管linux规定了一些框架规则，但使用方式在细节上难免有差别，因此只有多阅读源码或说明文档才能解决问题。我们在编写自己的应用程序和驱动程序时，也要尽可能遵照最*标准来写，这样方便与别人交流和共享。
冰山一角
2014-07-24
