最近一个星期的时间都毁在为在linux上写一个串口芯片的驱动程序了。先花了4天5天时间把LDD（Linux Device Drivers）看完了，然后花了2天看了一下linux自带的串口驱动程序到底是怎么写的，最后很幸运的用了2天把已有的串口驱动程序改写过来并且一把调通，真是心中暗存庆幸。
总结了一下自己的工作，得出这样的一个结论：磨刀不误砍柴工。 要写驱动LDD是必须读的，但是前提是必须对linux内核有所了解。我没看过完整看过Understanding Linux Kernel 这本书，虽然下过好几次决心要啃下来的，但是每次看到内存分配这块就睁不开眼睛了，但是网络部分我看过，此外我对linux的线程和进程机制还多少有点了解，知道什么是spin lock 。我想这些是基础，没有这些LDD也不用看了。看完LDD最大的感觉是哦，我懂了怎么去写驱动了，但是真的去看驱动程序的时候发现LDD看了和没看没什么区别－－还是不会写。但是这并不是说LDD什么都没有教你。
我说先看驱动程序的代码的，实在看不下去的情况下才无奈回过来看LDD，所以我对LDD的的作用有比较实际的理解。 LDD告诉你的如何去写驱动在实际中都是太幼稚了，因为在实际环境中驱动注重的是如何去和硬件打交道而不是去和系统打叫道。 但是LDD给你一些概念性的东西， 比如timer workqueue tasklet是什么，他们如何工作，我们应该如何使用，换一句话，LDD教育读者更多的是驱动程序中面向系统的方面。因此LDD只给出了驱动设计的一个偏面认识。全面的理解驱动，还是要去读linux驱动的源代码。
当然，在读完LDD后再去看代码，会突然觉得很轻松，那些繁琐的系统操作都变的熟悉了，驱动的设计思路更容易理解和领会了（BTW 读代码并不是好的学习方式，而是在open source中没有办法的办法，因为在一个自发的开发团体中，没有人有义务为他的设计提供对应的文档）。
说了很多LDD的坏话，肯定有不少的人会和我争论，我也觉得我说的这些并不是对LDD的客观平均。 我觉得我的这些想法只是从实用角度来片面认识LDD－－我在这里并没有想要对LDD本身来进行客观评论。为什么我还是要写这些，是因为我写的这些感受不是没有一点价值的，至少对于将要从事驱动开发的人而言是有益的参考。既然有益，何不笑纳之呢？
总结了一下自己的工作，得出这样的一个结论：磨刀不误砍柴工。 要写驱动LDD是必须读的，但是前提是必须对linux内核有所了解。我没看过完整看过Understanding Linux Kernel 这本书，虽然下过好几次决心要啃下来的，但是每次看到内存分配这块就睁不开眼睛了，但是网络部分我看过，此外我对linux的线程和进程机制还多少有点了解，知道什么是spin lock 。我想这些是基础，没有这些LDD也不用看了。看完LDD最大的感觉是哦，我懂了怎么去写驱动了，但是真的去看驱动程序的时候发现LDD看了和没看没什么区别－－还是不会写。但是这并不是说LDD什么都没有教你。
我说先看驱动程序的代码的，实在看不下去的情况下才无奈回过来看LDD，所以我对LDD的的作用有比较实际的理解。 LDD告诉你的如何去写驱动在实际中都是太幼稚了，因为在实际环境中驱动注重的是如何去和硬件打交道而不是去和系统打叫道。 但是LDD给你一些概念性的东西， 比如timer workqueue tasklet是什么，他们如何工作，我们应该如何使用，换一句话，LDD教育读者更多的是驱动程序中面向系统的方面。因此LDD只给出了驱动设计的一个偏面认识。全面的理解驱动，还是要去读linux驱动的源代码。
当然，在读完LDD后再去看代码，会突然觉得很轻松，那些繁琐的系统操作都变的熟悉了，驱动的设计思路更容易理解和领会了（BTW 读代码并不是好的学习方式，而是在open source中没有办法的办法，因为在一个自发的开发团体中，没有人有义务为他的设计提供对应的文档）。
说了很多LDD的坏话，肯定有不少的人会和我争论，我也觉得我说的这些并不是对LDD的客观平均。 我觉得我的这些想法只是从实用角度来片面认识LDD－－我在这里并没有想要对LDD本身来进行客观评论。为什么我还是要写这些，是因为我写的这些感受不是没有一点价值的，至少对于将要从事驱动开发的人而言是有益的参考。既然有益，何不笑纳之呢？
39万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
