《深入Linux设备驱动程序内核机制》第2章 字符设备驱动

MagicBoy2010

但是写书的话，大家不能想当然，你不能对你的读者做任何假设，每个人的技术积累以及达到的层次都是不一样的。。。初衷既然是出于分享自己的心得，那么就应该照顾到大多数人，而且既然是花钱买了你的书，咱得尽自己最大的努力对读者负责。遗憾是有的，所以需要后续不停地完善。。。

cjdao

楼主的书，正在学习中，和着ldd一起看感觉挺爽的！
每天看看各位的讨论都能学到不少东西啊。
挺赞成tempname2兄的观点的,往往只有从问题的本源出发，才能认识到现有的解决方法的精妙之处，才能对自己有更多的启发。

UnixKiller_Ama

MagicBoy2010 发表于 2012-03-19 22:26
1.中间扯FS扯得有点远了。
2.动态生成结点的机制演变了几次。开始是devfs，后来干掉了devfs只用uevent，现 ...

M兄说的IBM S390的bug是指这个吗？貌似已经有人fix了

http://www.spinics.net/lists/linux-s390/msg04838.html

MJK2012

关于软件的架构, 要分析给别人听时, 思考的深度顺序可以是, (个人想法, 仅供参考)

第一层 : 这个架构能做到什么东西

第二层 : 怎样灵活地使用这个架构

第三层 : 为什么要做出这个架构, 解决了什么问题? 没有它会怎么样?

第四层 : 为了解决某个问题, 为什么要设计成这样, 而不是设计成那样 ?

--

一段代码能活下来, 其实背后都不知道是抛弃了多少份不够好的实现了.

如果一定要求一本分析内核的书有深度的话,

那么下次可以出一本 , <<以源代码作者的角度去分析Linux内核架构的取舍>>

当然写这种书是很难的, 除了源代码作者, 谁知道他在设计时一共列出了多少个方案, 然后最后选择其中之一的.

就好像内存分配算法, 垃圾回收算法那样, 有很多种,  一般是选择一个合适的, 或者是多种方案混合使用.

听说以前某些牛人在做GUI的时候, 意见有分歧, 于是一个牛人就自己去创建了另一种GUI, 这也是各人有各人想法的结果.

---

所以, 上面你们提到的, 关于Linux内核的演化, 其实有一点这种道理.

演化, 就是用新的实现去代替旧的实现 , 这其中是包含了很多原因的, 每一次大大小小的改动, 都有更深的意义藏在里面.

MagicBoy2010

就本帖的主题而言，我认为书中的取舍还是得当的，对某些代码的解读可以帮助了解Linux下设备驱动程序的整体框架的幕后机制，比如对register_chrdev_region代码的分析，“代码想解决什么问题”？就是为了对设备号进行跟踪，防止多个设备误用同一个设备号的情况。踏空的方法论是值得提倡的，就是多问为什么，培养自己主动思考的习惯，这跟本书的内容并不冲突。书中只谈目前已经实现的机制，但是并不妨碍大家去寻求演化的进程。所以想法是好的，但是写书不现实。

如果再涉及到进化论的话题，我已经把那本《Linux进化本源》抛出来了，其实这个涉及到对架构以及设计优劣对比的问题，比如类似为什么要用设备号来访问设备驱动程序诸如此类的问题。这是个很狗血的话题，Linux本身大量吸收了unix的思想，如果追本溯源，那得追寻到unix当初设计时为什么采取设备文件这种做法，MSFT旗下也不乏骚人墨客，他们也有自己的设备驱动模型，讨论两种模型架构之优劣，就是口水仗。而且Linux的发展是部断代史与国别体混杂的产物，有很多问题从历史的角度很可能已经是无头公案了。如果当初换一帮人来设计unix，也许会是另外一个样子，但是历史不能重现，当初是否还有过别的方案，那得看unix历史这类的东西了。至于对同一个问题解决方案的演化，对Linux而言，几乎所有的演进都记录在LKML上了。。。我如果能象方舟子那么有空，整天坐在家里的电脑前整理各种材料的话，清理点头绪出来倒还有可能，不过那显然应该是另外一本书了。。。

MJK2012

回复 47# MagicBoy2010


  顶一下这段, 有意思.

frank529

飞速瞄了一眼，提几个意见，说得不一定对，姑且听之吧。感觉前面一段介绍应用程序和设备驱动互动实例有点多余，因为基本上有关内核驱动的书都有这段介绍，看的人也是熟的不能再熟了，所以很多人吐槽不够“深入”。我觉得要写关于内核的书，首先就要避免跟已有的书籍重复，重复的越多，书的价值也就越低。第二，很多内核的书都是抓着一个点往下分析，贴代码，讲细节，只是带着你一步步往问题里钻。钻了半天，可能某个细节明白了，但是整体上还是模模糊糊，就像盲人摸象。一个高明的作者，他应该是对内核的理解达到了一定的高度的，而且能够把读者带到他的高度，不用花费太多功夫，就能告诉读者你面前是一头大象，这是鼻子，这是耳朵...读者有了对问题宏观的把握，分析起某个部分来就更得心应手。当然这对作者的要求是相当高的，现在很少有书能达到这个高度，要么太泛要么太细，该泛的不泛，该细的不细。下班了，先说这么多，回头想到了再提。

MagicBoy2010

frank529 发表于 2012-03-22 18:53
飞速瞄了一眼，提几个意见，说得不一定对，姑且听之吧。感觉前面一段介绍应用程序和设备驱动互动实例有点多 ...

Frank，哥今天有点困，先把你这封信转上访办处理一下...

MagicBoy2010

UnixKiller_Ama 发表于 2012-03-22 08:34
M兄说的IBM S390的bug是指这个吗？貌似已经有人fix了

http://www.spinics.net/lists/linux-s390/msg ...

已阅，转拆迁办酌情处理。。。

frank529

举个例子补充一下，如果让我来讲字符设备，我会认为读者已经能很好的编写hello world的驱动模块，对file_operations有一定的概念（这部分LDD、宋宝华的书都写烂了）。那么我会先讲解用户空间和内核空间的，分析为什么要区分用户空间和内核空间。然后讲系统调用以及如何从用户空间进入到内核空间，然后讲字符设备如何注册，如何与设备文件管理，如何通过VFS打开设备文件和系统调用从而调用到驱动file_operations里面的回调函数的。这样读者对字符设备有个从顶至下的理解，每个部分的具体细节有兴趣完全可以通过深入分析内核代码去学习。当然，这是我对字符设备理解的高度，可能不算高，但是我会让读者站在我的肩膀上，俯视整个字符设备的结构，而不是去仰视它，觉得它有多高深，只能去一个细节一个细节的摸它，通过反反复复的分析理解，最后才明白字符设备是怎么一回事。
话说回来，这其实是我对所有内核书籍作者的期望，可能意见没有提到点上，请见谅。泛泛而谈很容易，可能实际做起来还是很难的，结构和篇幅都有很大的限制。
最后，我越来越感觉到Linux的设备驱动模型是基于面向对象的思想，但这种感觉很模糊，kset、kobject到底是怎样把各种设备、总线管理起来的？面向对象的思想又是如何体现的？如果您有空，能否请您写篇博客，像我说的一样宏观介绍下，让我们也能一下站在巨人的肩上，而不是被人牵着摸象？