深入理解LINUX内核

菊花医生 2012-04-01 0

研习中

八音 2012-04-11 0

很全的编程手册

finally 2012-05-11 0

介绍内核的书籍，体积庞大

閃光之刻 2012-11-06 0

想读linux源码的人可以看一下，不错的参考书

忽凌空 2015-11-11 0

经典的书，翻阅用

雨天 2016-10-14 0

十分怀疑翻译的功力和水平，英语能力和专业词汇过硬的前提下一定读原著

FutureChen 2010-01-12 0

正如简介所述作者给那些想知道自己机器工作原理的人提供了颇有价值的见解

digyourownhole 2010-07-22 0

without you L is nothing.magic word.Kernel.

scue 2016-05-28 0

经典书籍。

跑来跑去 2013-07-10 2

争取开始看英文的吧，看中文的，理解累，看英文的，阅读累。

路在脚下 2014-11-24 1

讲的很详细，适合中高级水平的Linux内核开发者，细读了一遍，对内核有了一个更好的理解，更适合作为参考书

interma 2008-05-18 1

比LKD更关注于细节，于是也更容易过时。。。。

菊花医生 2012-04-01 0

研习中

八音 2012-04-11 0

很全的编程手册

finally 2012-05-11 0

介绍内核的书籍，体积庞大

閃光之刻 2012-11-06 0

想读linux源码的人可以看一下，不错的参考书

忽凌空 2015-11-11 0

经典的书，翻阅用

雨天 2016-10-14 0

十分怀疑翻译的功力和水平，英语能力和专业词汇过硬的前提下一定读原著

我想说两句

准备这本读书哦

RainX 2005-10-07 1赞

虽然没读过，应该是本不错的书 :) . 但是我感觉一般来说O'reilly 一般会比较偏向于易读性而从某种程度上忽略了深度（当然是和国外的其他书比较，比起国内的很多垃圾书来说，o'reilly也算是有深度的了）。Ok 不管怎样，推荐一下啦

非常不错

popshvt 2014-08-16 0赞

这本书我读了不下20遍每次都有新的收获
作为内核的学习者我认为这本书和深入linux内核架构可以互相补充，然后直接浏览源代码不过 LINUX真是太复杂了单单这两本书也只能给你大概的认识更多的是浏览源代码

讲解linux内核的书皇，最好的一本，没有之一哦！

乌黑的船 2010-02-19 1赞

这本书太经典了，言语精炼废话不多，信息量大，细节较多。

但不适合做为学习linux内核的第一本书，最好是手头还有一本介绍内核原理的概括一点的书，先看原理，再对照看这本。一章一章对照看。

不要希望第一遍就完全看懂并记住，个人觉得最好的方法是首先粗略过一遍(前9章，到进程地址空间)，然后再细点看一遍，然后更细点。。。也就是说要一遍一遍的看。

这本书还需要点汇编，内嵌汇编的知识。

碰到读不下去不是很懂的地方，努力一番，但不要跟它死磕，有可能是翻译不是很到位，或是作者没有从最基本的开始讲起。要么先放过，回头再来啃它；要么勤动手，上网查一查，说不定有意外收获。

linux内核对普通学习者而言不亚于90度的悬崖，无路可循，这本书虽然没有让它变成一马坦途，但至少变成一个30度的斜坡，付出努力我们也能慢慢登堂入室。

linux开发人员必读

风很大，你说什么 2009-02-18 0赞

那是04年左右，在做一个无盘的linux发行版，始终无法支持视频解压卡，一直在零碎的查资料。最后还是看了这本书才让我真正的熟悉了内核开发，找到了好的解决方案。这本书非常系统的讲述了linux内核的组成。上可以衔接操作系统的课程，更好的理解现代操作系统，下可以为应用层开发提供更深层理解，更好的决策依据。

A good book providing an overview of the Linux ker

loader 2010-06-29 0赞

　　Overall it is a good book compared with other published books aimming for the Linux kernel domain.
　　　　
　　The strong point of the book is that it is very comprehensive and offers a clear overview of the Linux kernel, which on the other side, is also one of the shortcomings of the book. Basically, it is really hard for a book to provide many details while trying to cover every aspects of the Linux kernel.
　　　　
　　This book could serve as a general introduction or overview of the Linux kernel. Once you have the big picture by reading this book, you can delve into the Linux kernel source code to understand more details if necessary.

沉下来，把内功练到精深处

倚天屠虫剂 2015-07-19 0赞

这书几乎对Linux内核中的主要子系统的源码进行了逐行分析，确实需要我们静下来沉下心来，花一段不短的时间来阅读源码。
虽然我们自己去写一个操作系统的可能性很小，但是如果能深入理解这么庞大的系统，能阅读几万甚至几十万行优秀的代码，还有什么系统的源代码是我们不能理解的呢？仔细理解了这本书，仔细阅读了相关Linux内核源码，真的会让个人的内功大增，阅读代码的能力暴涨。
曾经读过LKN，可是只读过书，没有读过代码，没有写过实际的内核模块。这样下来自己收获着实不大，很多东西当时看过，可是不久就忘了。所以，还是要看源代码，还是要动手实践。
书好，更需要我们去读代码。

对于翻译我已经无力吐槽

wuzhouhui 2015-08-29 0赞

译者相当不负责任, 感觉他就是把英文句子逐词地翻译过来, 都不带调整的, 读起来相当生硬且晦涩, 审校更加不负责, 这样的翻译都可以通过?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?
我的评论哪儿短了?

书名是怎么翻译的

cuixiaole 2016-01-31 0赞

这本书的英文名是Understanding the linux kernel,怎么翻译成中文就是“深入理解linux内核”，“深入”在哪里，这么喜欢添油加醋，翻译别人的东西就不要自由发挥了，把意思翻译出来就行了，不必要添加这些无关紧要的东西

谈下我读这本书的经验

我私人的向日葵 2013-08-24 1赞

这本书读了差不多半年了。很难得的一本好书。我简单介绍下我的读书经验.
1) 第一章差不多是概述吧。初始看了觉得太抽象，但这章必须多次回顾，才能弄懂例如kernel control path以及kernel control path 交互等概念.
2)第二章并不大好。作者是只是简单地介绍了Intel芯片手册的protected-mode的内容, 但省略了很多细节, 所以读起来有些怪怪的,好像山重水复忽感无路的困窘. 但这章又是至关重要的. 如果这里没有学懂3级paging, page table entry等, 第八章第九章关于linear address, physical 和linear address space是看不进去的. cache也仅是简单的介绍一下。也许是因为作者觉得太architecture-dependent，没有详细介绍, 可是苦了我等自学者。所以我建议其他后来的读者去下载Intel芯片手册详细地研读这一章。事实上第三第四第五章第六章都是过于architecuture-dependent的，读ULK还不如读芯片手册来的更直观以及系统些. 当然ULK也不能落下, 毕竟透露了相关部分的源码细节.是非常有指导意义的的。
3)第三章讲的是进程管理，但是进程管理和虚拟内存是息息相关的. 因此建议第一遍了解就过了, 等看完第九章的进程地址空间以后，才返回来慢慢品味，绝对是回味无穷。另外这里和第七章调度器的管理一定要理解清楚:调度器调度, 进程切换。
4）第四章还是看芯片手册先, 但Linux kernel做了些自己的更改。所以两边都要看.
5) 同步这一章的话, 先了解下最好. 同步同步就是多个进程之间的协调。所以了解尽可，等看源码的时候你会对这块有很深刻的认识。当然这里涉及进程, 必须掌握第七章的调度以后才有深刻的了解.
6)第六章我感觉超有意思。它讲述了一个宏观和微观的概念. 即指令执行的纳秒级和每一次tick的毫秒级的故事. 把这个宏观和微观了解了，第七章的调度器太有意思了.
7)调度器.上面提到了。和进程以及计时器有密切的关系。
8）物理内存！这里是难难难点.因为它牵扯到第二章第九章第十六章第十七章。page结构体每一个成员都很有意义. 那一堆的标志在后面章节经常要回顾的.
9）地址空间！这里是重点中的重点。如果你要看懂这里必须要了解第二章的页表映射机制。基本上你把第三章和第九章以及第二十章都看了，你就了解应用层那些事了.
...
后面十二到十六章都涉及文件子系统...
...IPC和系统调用以及那些就懒得讲了。

linux kernel 是一个永恒的话题

风中散发 2009-04-21 1赞

对以所有学计算机的人，OS是一个永远都绕不过去的话题，一个主修CS的人，如果不懂操作系统，是绝对应该被鄙视的。但是可惜的是中国现有的CS培养模式，让绝大部分学生没有机会动手自己写一个kernel。

Mr. Process的一生－Linux内核的社会视角 (1)调度

马牛 2010-01-08 88

这里没法插图片，完整版（带图片和一些格式调整）见
http://www.manio.org/cn/scheduling-of-linux-view-of-society/

注：我看的是影印版，写得很好。

Linux内核是一个无比复杂的系统，要想看清大致的脉络也非易事。其实，可以把运行中的Linux想像成一个人类的社会，当中的进程就是社会中的人。人有生老病死，进程有创建、异常、终止。人有各种各样的财产，进程有对应的地址空间、设备等等。人被各种各样的东西限制着，被人管着，进程也是。内核无比巨大，从哪着手？我想，从进程的视角来看是个好办法。并且，在学习Linux内核的同时，类比人类社会来看，会有更深刻的印象，理解得更透彻。

本来也应该从进程的创建开始写的，但是最近在看调度的相关论文，就又把Linux调度的东西看了一下。所以，就先写调度相关的东西吧。

首先介绍与进程所在环境对应的人类场景：
这是一个公司，公司里有很多人（进程），每个人都有其对应的职称（优先级）。这个公司很奇怪，只有一张办公桌（CPU），在任意时刻，只能有一个人在工作(TASK_RUNNING正在运行状态)。其他人呢，要么在休息室时短暂地休息（对应TASK_RUNNING就绪状态），要么就在寝室Sleep(对应TASK_INTERRUPTABLE或TASK_UNINTERRUPTABLE)，要么就是死人了，在停尸间（TASK_ZOMBIE）。是的，这是真的，这个公司就是个血汗工厂，干活累死了，就直接丢进停尸间，惨绝人寰！

以下是此公司的平面图：
（我是没法插进来的图:( ）
图解：“推门”是单向的：比如连接工作室和太平间的是推门，职员只能从工作室走到太平间，不能从太平间走到工作室（这太吓人了）。
“凹槽门”是双向的：比如连接工作室和休息室的门是凹槽门，职员可以走来走去。

时间片(time slice)：这个公司的工资特别高，按工作的小时数计算。工作者得钱，不工作者不得钱。所以，所有的人都特想去办公桌那里工作，争着抢着要去。为了让大家都有机会去工作（避免有的人没钱拿，饿死，i.e. starve to death），所以公司出了条规定，每个人每次工作的时间不能超过公司分给自己的时间片（time slice）。时间片的大小由此人的职称决定。

职称（也就是内核中的priority）：职称有两种，一种是静态职称（static priority），一种是动态职称（dynamic priority）。静态职称是先天的，由此人的老爸决定（富二代有先天优势！）。动态优先级是看在公司里的工作表现的。职称是很重要的东西，职称越高，你到办公桌上赚钱的机会越大。

默认时间片长点好还是短点好？
自然是不长不短好（世界上的事情都是这样）。如果太短了，比如说某职员时间片是1分钟（对应的Linux里的时间片应该差不多是0.1ms吧，可能还得少点），这个人在办公桌前屁股没坐热就要走了，从起身到回到休息室，再到下一个人起身走到办公桌前坐下，这也得要一分钟。如果这样的话，这公司将有一半的时间花在走路上。这样搞是不行的，在资本主义社会，大家都要努力搞高生产率。

那是不是时间片长了就好？也不是。比如时间片是一个小时，当两个客户（对应Linux中的两个用户）同时要和此公司展开业务（对应Linux中的启动进程），有两个职员会分别处理这两个业务。A职员一上去就占着办公室一个小时，B职员在这一个小时结束前没法子处理他的客户的业务，所以B职员的客户就得在寒风中等一个小时！资本主义社会里的公司是不能让他们的财神爷不高兴的。所以，还是不长不短的好。

回到真实的Linux内核中:很多人认为时间片过长会导致程序的响应（比如字处理程序的I/O响应）变慢，因为要等时间片用完才能处理。其实不然，字处理程序等交互性强的程序,他们的优先级高，可以抢占当前正在运行的进程，从而得到执行。在公司里，就比如B职员的职称高，他可以把A职员从办公桌上踢走。事实上，从后面对动态优先级的讨论我们可以看到，要是A职员一直霸占着办公桌不走，他/她的动态职称会变低的，结果是，在休息室里的其他职员的职称就自然而然地可能比A高了。

职员目录(Process list)：公司有个目录，在这个目录中，列出了所有公司的职员。这对应Linux里的Process List，里面存有所有进程的信息。

下面以Mr. P的经历为例说明
Personal History Statement of Mr. Process （Mr. P in short）

出生
这是世界上最怪异的公司，职员都是单性的，都是男的。并且不要交配，自己调用系统调用fork()，就可以生了。生出来的小孩子也都是男的。

在这里为了问题的简化，就只讨论与调度的关系比较紧密的内容。

（我是没法插进来的图:( ）
图：详细的公司平面图

如上图所示，在休息室里其实还有两个沙发。一个沙发叫做活动队列（往后我们叫它活动沙发吧），一个沙发叫做过期队列（往后我们叫它过期沙发）。坐在活动沙发上的职员都还有时间片没有用完，坐在过期沙发上的职员的时间片刚刚被用完了（但他们手上都拿着新分配到的时间片，这个是2.5版内核新引入的O(1)调度，后面再讲）。

Mr. P的父亲在办公桌旁边工作的时候，突然fork()了一下，就生出了Mr.P。一出生，Mr. P就拥有和父亲一样的静态职称（static priority）。他一出生就坐在了活动沙发上，拿走了父亲一半的时间片。比如生MR. P之前，MR. P的父亲有10ms的时间片，MR.P出生后，他父亲有5ms，Mr. P有5ms。这样的机制是为了防止有人以生子来抢夺时间片：试想，有一人，自己有10ms的时间片，他一直生啊生，生了100个孩子，那么这个程序就有了10+10*100ms的时间片了。然后他的孩子断续生啊生，那么有可能系统中绝大部分的时间片都是他家的了，那他的街坊邻居还要不要活啊，没时间片等于不能做事，等于没工资，等于没食物，等于饿死。

另外，不幸的是，即使是在发达的资本主义社会，孩子也是有可能夭折的（由于各种原因，在第一次到办公桌上工作之前就死掉了）。在这种情况下，公司会把孩子没用的时间片还给他父亲。多么人性化的公司…

开始工作
像其他所有孩子一样，Mr. P一生下来就能工作了，他坐在活动沙发上等着做事。他人事部的同事Miss Schedule (以下简称Miss S)会在每个tick(内核的时间单位，时间很短)结束时检查一下以下两种情况有没有发生：
1. 在办公桌前工作的那个职员是不是已经用完自己的时间片了。
2. 是不是有更高动态职称（dynamic priority）的职员在活动沙发上等着。

其中一种情况成立，这个在办公桌前工作的那个职员就要被赶出来，换在活动沙发上坐着的动态职称最高的职员进去工作。

假设经过一段时间后，没有人的动态职称比Mr. P高了。在一个时间tick结束时，Miss S到休息室检查大家当前的职称。他能轻松地找到动态职称最高的职员(sched_find_first)，因为职员们都是按动态职称来坐的（在活动沙发上），动态职称相同的职员坐在一起（参考struct prio_array）。Miss S只要按顺序找下去，第一个在沙发上找到的职员就是职称最高的。当Miss S用上面的方法发现Mr. P当前的动态职称是最高的时，在办公桌前工作的是职员C，Miss S把C从办公桌前拉到休息室。如果此时C的时间片已经用完了，他就会被安排坐在过期沙发上（这也就是expired的含义）；如果此时C的时间片没有用完，他就会被安排坐在活动沙发上。C被拉到休息室时，他的工作用具，笔啊纸啊什么的，都要从办公桌上拿走（这是关于进程上下文切换的问题）。C走了之后，Mr. P带着他的东西到办公桌前坐下，整理好办工用品（进程上下文切换）。好的，Mr. P可以开始工作了。

评定动态职称

公司里的两类人：
交际花（I/O消耗型进程）：这类人常常与外部的客户打交道，而客户的反应总是不怎么快。所以，交际花常常要等客户做出反应。公司为了不让交际花在等客户反应的时候也占用着办公桌，所以，当交际花要等待客户的响应时，他就会被移到寝室去睡觉(Sleep)。
工作狂（处理器消耗型）：这类人就是传说中的苦干王，很少和外界打交道，就知道在办工桌上做事。这种工作狂给公司造成一些困扰，如果他们老占着办公桌，交际花就没法做事了。要知道，一个公司还是需要人去跑跑业务的。

公司有一套机制，这一套机制能很好的区分这两类人，并且给他们评定职称。判断的标准就是他们的平均睡眠时间（average sleep time）。睡眠时间包括在寝室里的时间（TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE）和在休息室时等待的时间。但平均睡眠时间的计算并不是加和再求平均那么简单。在TASK_INT和TASK_UNINT两种状态下，平均睡眠时间的增长情况是不一样的。在运行的时间，平均睡眠时间是在减少的。具体的平均睡眠时间的算法在recalc_task_prio()中。

当一个职员常常睡觉，公司就知道这人是交际花了，因为他常常因为等客户的响应而睡觉。当一个职员很少睡觉，公司就知道这人是个工作狂了，因为他很少因为等客户的响应而睡觉。

现在我们回来讨论Mr. P，假设Mr. P在工作的时候要等待一个客户给数据给他(比如说键盘数据)，他就把自己的加入一个等待队列里，将自己设为TASK_INT，这样他就进入了寝室里。Mr. P在那里苦苦地等待他要的数据到来。终于，客户敲下了键盘，给出了数据。然后键盘事件的管理者调用wake_up()函数，将Mr. P唤醒。如果Mr. P的动态职称高于当前正在工作的职员的动态职称，那么Mr. P就会抢掉这个职员的办公桌。如果不高于的话，Mr. P就只是先到休息室里坐着。我们假设Mr. P的动态职称很高，所以，现在Mr. P又抢到了办公桌。

O(1)调度
又过了一段时间，Mr. P的时间片用完了，该离开了。这时他该被Miss S带到过期沙发上了，在从办公桌走到过期沙发的路上，Miss S会帮他重新算时间片（依照动态职称来决定时间片的长短）。事实上，每个职员被带到过期沙发上坐着的时候，Miss S都会帮他算好时间片。这样，过期沙发上的所有职员手中都拿着时间片。这样做的好处是，当活动沙发空了的时间，只要把活动沙发和过期沙发上贴着的“活动沙发”和“过期沙发”的标签互换一下，原来的过期沙发就变成了活动沙发，原来的活动沙发就变成了过期沙发。这样，Miss S就又可以从活动沙发上叫人去工作了。而这个“互换标签”的动作的时间复杂度是O(1)。这就是2.5版内核所引入的O(1)调度。

试想一下没有这个O(1)调试之前是什么情况：每次所有进程的时间片都用完时，要重新计算所有TASK_RUNNING状态的进程的时间片。当一个系统中只有几个进程的情况还好，但是对于有成千上万个进程的大型系统，这是相关耗时的。

对交际花的优惠政策
在一个公司来说，交际花是非常重要的，他们的表现直接关系到客户的满意度和公司的形象。所以，Linux公司有一些专门针对交际花的优惠政策。

假设Mr. P就是一个十足的交际花：上班打扮得花枝招展（虽然是个男的），见人说人话见鬼说鬼话，关键是，他有一些客户特别爱和他把交道。当Mr. P用完一个时间片的时候，照常理，他是应该被Miss S带到过期沙发上去等待下一次工作的。但这样的等待有可能太久了－要等到所有活动沙发上的职员都用完时间片。所以，Miss S为了客户的满意度（如果等太久，客户是不满意的），就在重新计算Mr. P的时间片之后，让他留在了活动沙发上。这样，Mr. P就能更快地处理客户的IO事件。

这看起来是对交际花的特权，其实这是为了公司的长远利益着想。如果客户的需求得不到及时的满足，客户不满意，就不会有人用这公司的产品了，即使工作狂们的工作做得很好。

公司里的超级特权阶级－小霸王(real-time process)
交际花是有一些特权，但权利再大也大不过小霸王。公司有时会有一些时间很紧的项目要做，这些项目有deadline。为了能完成这些重要的项目，公司里发展了一种特权阶级，就是小霸王。他们的职称高于其他所有普通员工，除非他们完成了自己的工作，否则其他职工不能去工作。

这些小霸王的工作方式有两种：
FIFO(First In First Out)：当一个小霸王完成自己工作的时间，其他小霸王才能去工作。但是当有职称更高的小霸王到来时，职称更高的小霸王能抢占当前的小霸王的办公桌。
RR(Route Robin)：相同优先级的小霸王转着用办公桌，每人用一段时间。

总结：
在这篇文章里，以Mr. P的工作经历来说明了Linux调度的一些比较重要的机制。介绍了IO消耗型进程和处理器消耗型的进程，O(1)调度等等。这些是比较大的方面，当大的方面理解了之后，那些世界顶尖高手写的源码也就更容易看懂一些了。

灵与肉的结合

卉 2011-11-04 36

  曾几何时，我们为调试成功第一段汇编小程序而欢欣鼓舞，为写完C语言小程序通宵达旦，为自己的数据结构解决了一个实际问题而踌躇满志。再后来我们学习了计算机组成原理或者高级点的计算机系统结构，学习过操作系统的实现和设计，看过算法导论...但好像一切又渐渐变得遥远了，虽然书本上的一切也都感觉上能理解，但总是朦朦胧胧觉得缺少点什么，或许是觉得所有的知识都是断断续续的，感觉很多知识是无本之源。但这本书拂去了一切挡在眼前的薄薄尘埃，让我看见所有的一切都在这里完美结合了，有如灵魂和肉体的结合，一切都富有活力起来。汇编、数据结构、算法、操作系统理论、计算机系统结构、C语言、编译器等等好像都在这里闪动着五颜六色的极富魅力的小光线，我揉了揉干涩的眼睛，渐渐地，我看清了它们组成的光芒照耀着的是操作系统...

  看的是影印版，本书特点：
    1.也是最大的特点，用足够多的汇编来介绍操作系统的一些功能如启动、切换、同步、中断。汇编(不是DOS下的汇编)是了解操作系统跳不过去的坎，有了至少一种CPU汇编的理解，其实相当于理解了相应CPU的架构，这才算真正的开始了解操作系统。这本书是汇编和Linux操作系统的桥梁。
    2.对编译操作系统需要的编译选项也做了不少铺垫，真的算体贴入微了。
    3. 有如外科手术刀，提供了很好的几个断面来了解Linux。即使这么复杂的系统，也能这样娓娓道来，非常不容易。循序渐进、深入浅出，书中出现的未知内容或者重要概念一般会提示你在哪里查找。

    本书是我看过花费时间最长的书，总结原因如下：
    1. 知识量大：操作系统本身概念多、难点多、平时接触少。
    2. 细节太多：本书主要从下至上的形式讲解，一开始就有太多的细节(汇编、数据结构、函数)，需要熟读几遍的基础上才有可能再从上到下的方法进行总结，知道了重点和纽带，思路才变得慢慢清晰起来。遗忘和迷失方向是经常的，每次学习也带来新的自我提问。查看相关代码的数据结构、函数、相互引用、书本内容的确认需要很多时间。另外Linux 2.6是个实际运行系统，太多的错误处理、接口、参数和扩展等，使得源码变得更加晦涩难懂。
    3. 内容交织：书中几乎每一章与其他章节都联系紧密。仅仅一个函数，可能引用了书中很多其他章节或操作系统的许多概念，变得非常难以理解(如Page Fault Exception Handler(P376))，因此你根本无法仅依赖熟读某一章里面就完全了解这一章内容，而且几乎每一章都包含一些后面章节未介绍的概念，很多时候觉得有点无处下手。每个功能的区别可能用一个位来表示，变得非常隐晦，很难记住这么多。操作系统的概念介绍一般包括功能、实现方式、数据结构、相关函数(算法)、汇编实现、全局变量、初始化、正常关闭等。同时每个概念的实现中还可能包括系统调用、特殊文件目录(/proc或/sys)、shell命令、系统初始化(start_kernel下的函数)、权限、资源、中断、信号、编译选项、统计等。因此也积累了无限的可能，这也许操作系统难学的原因吧。操作系统的复杂也许来自于层次性和不可分割性。

  看了本书的体会：
1. linux操作系统让数据结构、算法、计算机系统结构、汇编、驱动、有了驰骋的疆场。操作系统的设计理念得到实现或试验，而不是仅仅停留在白纸上。
2. 问题的思考层次，编程中出现的问题能尝试从多层次出发进行考虑，如CPU指令/操作系统实现(包括模块和驱动)/系统函数接口/C函数接口/应用系统，理解操作系统在其中能起到的桥梁作用，同时兼顾编译器的帮助。
3. 这本书打开了无数扇窗，每一扇风景都等着你去发现。这本书只是认识Linux操作系统的开始，这本书理论为主，实战少。但是经过这本书磨练，实际工作中的碰到的操作系统中大部分的概念，你都可以自己在源码中得到证实，而不是“好像觉得","牛人说","书上说"。
4. 对windows操作系统也会有新的认识，并且尝试重新认识数据库、java虚拟机等。

  本书的重点总结:
1. 汇编 head.S entry.S 与启动、切换、中断、系统调用等相关
2. 内存管理(P35,P294)
3. 程序切换和调度(P102, P290)
4. ext2文件读(写)过程：结构图(P561) 理解每一层的做什么
5. 各个层的缓存、各种缓存技术(LRU,cache, hot/cold page…)，,以及页面回收算法RFPA
6. exec过程(P828)：

ext2文件读(写)过程：结构图(P561) 理解每一层的做什么
read(P508) 【层：User Mode】
-->sys_read-->vfs_read-->file->f_op->read() 【层：VFS】
  ---->generic_file_read(P632) 【层：Disk File(Block Device File)】
    ------>do_generic_file_read(p635)-->do_generic_mapping_read 【层：Page Cache (inode)】
      -------->ext2_read_page(P638)-->mpage_readpage() 【层：ext2】
        ---------->submit_bio()-->generic_make_request(P570) 【层：Generic Block Layer】
          ------------>__make_request -->q->add_request() 【层：I/O Scheduler】
  相关request在I/O Scheduler队列中的 q->request_fn函数(即do_hd_request)调用：
  do_hd_request(以HD.c为例) 【层：Block Device Driver 取队列，发起读请求】
     -->elv_next_request(),
     -->hd_request()
  read_intr() 【层：Block Device Driver中断，读数据，从队列中删除，再发起请求】
    -->end_request()
       ---->end_that_request_first()
       ---->blkdev_dequeue_request()
       ---->end_that_request_last()

共享内存(P801)、文件映射(P657)、直接文件读写的区别
a. 共享内存的缺页：
do_no_page (预先在mmap()-->shmem_zero_setup设置shmem_nopage ）
  -->vma->vm_ops->nopage
  -->shmem_nopage
    ---->shmem_getpage
       ------>find_lock_page
       ------>shmem_alloc_page
       ------>add_to_page_cache_lru
b. 文件映射的缺页：
do_no_page(预先在mmap-->file->f_op->mmap设置filemap_nopage)
  -->vma->vm_ops->nopage
  -->filemap_nopage
    ---->find_get_page
    ---->mapping->a_ops->readpage(一般为ext2_aops.read)
    ---->ext2_readpage 函数直接读写 ext2文件系统，inode缓存由前面的步骤建立了。

c. 文件映射和直接读写文件相同点：
  i. 都调用ext2_readpage函数，则ext2层以下完全相同
  ii. 都采用inode的Page Cache,由直接文件读写的do_generic_file_read和文件映射的filemap_nopage分别建立
  iii. 都可能尝试磁盘的预读。
d. 文件映射和直接文件读写不同点：
  直接读文件，修改后并写入文件：数据需要从内核态-->用户态复制一次，再从用户态-->内核态复制一次，还可能需要两次高端映射。


相关参考书目:
  <深入理解计算机系统>
  <Intel Achitecheture Software developer's manual>
  <Unix 高级编程>
  <Linker & Loader>
  gcc 文档

附：
  不过就在昨天，我觉得自己是个碎片，在生命的苍穹中毫无节奏地颤动。
  如今我知道自己就是苍穹，一切生命都是节奏分明的碎片，在我内在活动。.....纪伯伦

一本好书让不负责任的翻译给毁掉了

liangc 2009-10-06 25

因为要做内核相关的东西了，理所当然的买了这本书，刚读了开头就觉得：一本好书让翻译给毁掉了。并不是说技术上不行，而是这些个翻译的态度就不端正！比如刚开始第一页，把SVR写成了SRV，下面的注释中竟然把linus torvalds的名字写错了。虽然不是什么大问题，也不会影响到读者理解linux，但是这反映了一个态度问题。这能说是译者技术不行吗？明显是态度不端正！
而且目前国内的翻译存在一个通病就是请国内知名教授来翻译外国名著，那些教授哪有时间来做这些既耗时间又不赚钱的事情。通常他们的做法是找几个他的研究生给他们当作业，然后教授在前面挂一个名字。其实可能教授本人根本没有读过翻译的稿子就直接给出版社了，而出版社编辑又不懂计算机当然只能按着稿子照搬了，然后把知名教授的名字写在最前面，不然书卖不出去啊。
这本书吧，陈莉君教授也算是国内linux知名教授了，把她的名字放在第一当然书就好卖了，其实她并不是译者，只是校审，那两个估计是她的研究生。当你读了这本书后就会想：校审到底有没有读过这本书？

书是好书！但是对读者的要求有些高

敬承文 2006-04-10 12

非常棒的内核方面的书！我买了很久了。多久？大概快一年半了。我虽然喜欢Linux方面的书籍，但在书店逛的时候，大多不会买：站在那儿，一会儿就能够翻完的书，从含金量方面考虑，值得买么？
而这本书，含金量是足够了，但是看起来非常耗时，非常基础的底层技术：汇编知识（主要是X86体系的硬件接口知识）、C/C++功底、数据结构，因为没有提到网络方面的内核代码，所以对TCP/IP协议没有要求，如果对这三方面缺少认识甚至没有听说过的话，建议看之前还是充充这方面的电，不然会自信心会遭受严重挫折。 :P

翻译,,,很雷

夜的旅者 2009-08-23 10

很多句子都不变换一下语序,不知道是偷懒还是连最基本的翻译技巧都不知道。最过分的是常用的说法翻的也不够地道，最典型的是“上下文”被翻成了“文境”，但搞笑的是在附录的索引里却翻成了“上下文”。还有很多术语也不符合常规的说法，看的很不爽！

值得钻研的一本书

勇敢的萝卜 2013-10-19 4

首先，我要强烈建议的是：这本书一定要看英文版的（买不到的话可以网上下pdf，然后淘宝上打印）！

其次，我还要提醒一下linxu kernel的初学者：读这本书之前，要看一些讲解操作系统原理和概念的书。

最后，对于初次看这本书的读者来说：不要指望读一遍就把这本书都搞懂。因为这部书各个章节之间（实际上是kernel的各个部分之间）是有交叉的，综合起来看才能得到一幅完整的图景。

最最后，耐心是很重要的；不要追求速度（当然，如果您的理解能力和学习能力很强，就是学得快，请无视我所有话，除了这句），读懂书才是读书的目的。

本书（第三版）勘误~

XA™ 2010-12-07 3

一、硬伤
P101L4 ~ L6的内容为:
"没有为处于TASK_STOPPED、、EXIT_ZOMBIE或EXIT_DEAD状态的进程建立专
门的链表。由于对处于暂停、僵死、死亡状态进程的访问比较简单，或者通过PID，
或者通过特定父进程的子进程链表，所以不必对这三种状态进程分组。"

L7 ~ L9的内容为：
"没有为处于、状态的进程建立专门的链表。由于对处于暂停、僵死、死亡状态进程
的访问比较简单，或者通过PID，或者通过特定父进程的子进程链表，所以不必对
这三种状态进程分组。"

对应的英文原文为:
Processes in a TASK_STOPPED, EXIT_ZOMBIE, or EXIT_DEAD state are not linked in specific lists. There is no need to group processes in any of these three states, because stopped, zombie, and dead processes are accessed only via PID or via linked lists of the child processes for a particular parent.

Processes in a TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state are subdivided into many classes, each of which corresponds to a specific event. In this case, the process state does not provide enough information to retrieve the process quickly, so it is necessary to introduce additional lists of processes. These are called wait queues and are discussed next.
翻译：TASK_可中断或 TASL_不可中断状态的进程被细分为很多种类，每一种都只响应某一特定事件。这种情况下，进程状态无法提供足够的信息以快速解析进程，所以需要引入附加的链表。它们被成为等待队列并且接下来讨论。

二、错别字
P46L-3 "80x86微处理器中的分段鼓励程序员把他们的程序化分乘逻辑上相关的实体，例如子程"
此处"化分"应该为"划分"。

P49L-9 "与高级电源管理(AMP)..."
P49L-5 "像前述与AMP相关的3个段的情况一样,..."
AMP应该为APM

P61L-7 "(Page Cache Disablt)标志指明当访问包含在这个页框中的数据时,"
"Disablt"应该为"Disabled"。

P71L-12 "...例如，IBM Thinkpnd把"
很明显的应该是"Thinkpad"。

三、有些地方有尾巴
p598L11 "spinlock_t tree_lock Spin lock 保护基树的自旋锁"
此处的"Spin lock"系多余的。

四、半角全角不分

只是大致的翻一翻，希望仔细看过这本书的再挑更多的错误。有了第一个硬伤，充分说明这些翻译们的辛劳和严谨。真的太有才了，在译者序的最后有"......为第二版和第三版之间的差异做了大量校对工作，同时还参与部分翻译工作。全书由陈莉君审校并统稿。"不知道陈老师是否真的统过稿，值得怀疑。

等多请看原文：http://www.chinaunix.net/jh/4/914783.html
英文版官方勘误：http://www.oreilly.com/catalog/understandlk/errata/

翻译的不好，凑合着能看

simonliu 2010-08-10 2

书名叫“深入理解 Linux 内核”，其实读起来感觉并不是很困难，只要有一些操作系统基础知识和 x86 芯片知识就能读懂。全书大部分都比较有趣，但是内核数据结构本身就很复杂，本书为了“深入”二字，列举了大量的内核数据结构，并且几乎给出这些结构体的全部属性，读起来感觉很晕。

力荐

bigrat 2010-11-24 2

同事买了这本书，然后裁成5本，以便携带，方便上下班地铁上看。我就借机一本本要来看，重点看VM的部分。

没啥说的，讲的很清楚，边看书边看代码，收获很大。

论坛上有人反应此书翻译的不好，我没这感觉，可能文字看的不仔细吧。

准备这本读书哦

RainX 2005-10-07 1

虽然没读过，应该是本不错的书 :) . 但是我感觉一般来说O'reilly 一般会比较偏向于易读性而从某种程度上忽略了深度（当然是和国外的其他书比较，比起国内的很多垃圾书来说，o'reilly也算是有深度的了）。Ok 不管怎样，推荐一下啦

我要写长评

想读在读读过

标签(多个标签以“，”分开):

保存

深入理解LINUX内核

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读