内核日记
前些天读“linux内核源代码情景分析”（毛德操），觉得开始写得还不错，后面的讲解过于细节，让人不能从整体上有个把握（看了几本国内写的内核的书，好象都是给几段编码，加点注解）。我感觉，即然内核也是一个软件，就应该以软件工程的方法去理解它。用软件工程设计方法当然是：需求，总体设计，详细设计，编码等等。我想老毛的书基本在编码讲解层次上，让人不能有一种宏观把握的清晰思路。我感觉要读懂源码，应该首先从总体上理解，即弄明白设计理念，其次才是具体的编码理解。所以我这两天转向从总体上把握它。现在在读＜深入理解linux内核＞，它写得很好，我已读了中断异常，时钟中断，进程几章，它把中断异常，时钟中断设计的思路讲得非常清楚，我推荐大家读一下此书。
我有个问题还没想太清楚，请大家指点：
一个进程要进入TASK＿INTERRUPTIBLE OR TASK＿UNINTERRUPTIBLE状态，这应该具备什么条件，及如何唤醒（能不能醒就看进程能不能被放入就绪队列）？
这个问题我想了又想，觉得：
进程要睡觉有自愿和被迫两种
自愿，主要是调sleep_on()等，他们的唤醒靠挂在定时器上的函数，此函数会把相应的睡眠进程放入就绪队列，从而唤醒了进程。
被迫方式主要是因为等待事件。等待事件我理解为等待某信号量可用，当内核函数帮进程检查某信号量是否可用时，若发现不可用，内核函数就会把进程挂到等待队列中（信号量的队列中，好象挂到信号量的队列中便没必要挂到等待队列中，只要不让进程挂到运行队列便可），不让进程被调度。当某进程释放信号量指示的资源或发出某事件时，它会调用类似的PV操作的V操作函数，此V操作函数会把等待进程放入就绪队列，从而唤醒了进程。
这便是我对进程睡觉和被唤醒的理解，不知正确于否？欢迎发表你读内核的感受。
相互交流，共同进步 [color=blue]对于你说的一个进程要进入TASK_INT...,TASK_UNINT...状态应该具备什么条件,我的理解是要看进程的决心,也就是如果为了等待某项资源而去睡眠,那等待那项资源的决心决定了他是深度睡眠还是小睡,因为前者是可能会被一个信号唤醒的,这个时候如果没有特殊的处理一般就不会继续睡眠等待,从而从系统调用里失败返回,返回个例如(?)错误码表示系统调用被意外的情况(这里是信号)中断了.如果是深度睡眠,则表示不会被信号打扰.至于其他的睡眠,比如自愿让出控制权一般都会设TASK_INTURRUPTIBLE,而不会是后者[/COLOR]
跟踪进程如何查被跟踪进程的内存数据？
首先声明一下，本人一不小心把贴子发错位置了，放到了“内核源代码学习”，所以我在这里又放了一份。所以你若回贴，请回到内核日记里。很是抱歉。
今日日记：
我想再问一个问题：
进入TASK＿INT..,TASK_UNINT..的是不是都必须处在某个等待队列中？
我的理解是：有的进程进入睡眠态根本不挂入等待队列，
理由是：比如定时睡眠（内核函数为：sleep_on_timeout(),
interruptible_sleep_on_timeout())，这些函数会为进程申请一个动态定时器，然后把定时器的data域设成进程的PID，这样当定时器到时，便会把进程唤醒，这就没有用到等待队列。
不知理解正确于否，欢迎指正。
今天看了信号量机制和内存管理（buddy算法和slab分配器，还有点问题，不过等看完再提），还有就是跟踪系统调用。
我想就跟踪再提个问题：
硬件对跟踪提供了两种机制：eflags的IF标志，调试寄存器组
linux在进程控制表中提供：PF_TRACESYS标志用来中断系统调用
（不知还有没有别的方式？）
当A进程被B进程跟踪时，B则为A的父进程（这点应该没有问题吧），若此时A遇上断点被中断，它会进入TASK＿STOPPED状态，B会收到一个SIGCHLD信号，从而被唤醒当B运行时，它会检查A的状态，无外乎是看 B的硬件上下文，B的某内存数据，或B的进程控制表中能体现的所有信息。（还会不会看别的什么？）
我现在想问：B通过系统调用要求看这些信息时，内核如何服务？
我把我的想法写出，欢迎补充指正：
1。B要看A的寄存器和进程控制表中能体现的所有信息，内核只需从进程控制表中提取便可。
2。B要看内存某内存数据，则应该给系统调用传地址参数，内核就必须想法找到
A的地址空间中找到此数据，如何找呢？（这是问题的关键） 我想内核会利用A的页全局目录，采用计算方法找此数据的物理地址，然后利用内核的内存的固定映射方法得到在A空间的线性地址（此地址＞3G），然后就可以访问到此数据。
不知我的理解是否正确？
2003.04.19读核日记：
2003.04.19读核日记：今天看内存管理，深感知识面不够！
在内存管理的3个主要数据结构：BUDDY算法，SLAB分配器，vm_area分块，其中slab最难理解。
现在有一点不太明白，提出来请大家指点：
kmalloc,vmalloc,malloc有什么区别？
内核通过buddy对大块物理内存进行管理，通过slab分配器对零碎的数据结构提供
分配服务，这样内核所需的内存无论大块小块都有函数可用了。
那用户进程的内存空间如何管理？内核通过vm_area_struct技术实现用户线性空间大块内存分配，比如：代码区，数据区，堆区，栈区。我现在想问，当进程需要小块内存时，由谁来管理？我知道，一般用户通过malloc来分配零碎的内存。
但malloc通过什么方法来对得到零碎内存，是通过系统调用，还是不用系统调用？我查了系统调用，好象没有相应的系统调用，我又没有发现内核为用户空间的零碎内存管理提供任何算法。所以我怀疑malloc没有用系统调用，可不用系统调用它又用什么方法来实现呢？我想了以想，觉得若malloc不用系统调用，则它必须自己来管理，即它必须自己建立一个管理数据结构，那又用什么数据结构呢，最简单的方法就是用链把已分配的零碎块串起来，复杂一点的话也可仿slab来管理。
不知大家谁对malloc的分配机理清楚？若大家谁有C库源码，不妨共享一下。
对了，还有一个问题？
对库如何实现反汇编？ [Color=blue]我在挺早以前看过这些反配机理,只是现在好多都忘记了,slab机制在linuxforum那讨论的比较多,至于malloc,它用的是brk系统调用,主要是作堆和栈(堆在下,栈在上)之间的那块空白虚存空间分配资源,情景分析对它讨论的十分十分的详细,你如感兴趣,可以参考[/Color] [Color=blue]gcc库的源代码你大概应该可以在gnu或者gcc的网站上找到吧[/Color]
再问malloc
brk只能修改堆栈的大小，或着说是边界，而且它是以页为单位。malloc肯定要利用brk，但是malloc必须实现页内的小对象的管理，必须在页内一小块一小块的割内存.而这是brk无法胜任的
所以我怀颖malloc要自己实现小对象的管理。
不过我还没证实。我已下载到C库的源码，不过可能一时半会还看不懂。 [Color=blue]我也没看过gcc库关于malloc的源代码,不过我以前的想法就是管理用户内存有它自己的一套管理办法,包括分配释放管理等等.我记得在绿色联盟上有一篇关于malloc漏洞的文章,你可以去看看,它讲的挺好的[/Color]
2003.04.20读核日记－－未来LINUX架构随想
2003.04.20读核日记－－未来LINUX架构随想今日浏览了一下VFS，对它的设计思想很是佩服。它实现的思路我的理解就如
PCI插槽，插上不同的独立设计的具体文件系统，便可扩展功能。
所以与其说VFS是一个通用文件系统的接口，不如说它是一个技术规范。
通过这种规范，可实现不同的软件的无缝对接。
再联想到POSIX，不也是OS设计的规范吗，所以我想，会不会有一天能把linux
的各部分之间也设计能用规范相联，就如同组装PC机一样。不过，令人心慰的是
VFS已经实现了文件系统与具体文件系统的规范。我想下一步应该把内存管理也设计成规范，linux其它部分只通过标准的函数接口就能完成从物理内存分配，回收
，进程空间的管理，还有缓冲的管理。说到缓冲的管理，我想linux内核的缓冲主要有两大类：一是固定对象的分配回收的缓冲（或叫缓冲池），如通过SLAB进行的小对象分配机制。二是高速缓冲，如磁盘块的预读管理，页面的老化等。应该把这两种缓冲管理也标准化。 说不定到那时，我们也可象设计具体文件系统那样把内存管理单独设计成一个模块，然后不用重编内核，就可以把原内存管理模块通过如INS＿MM＿MODE的函数换成自己设计的内存管理模块。我都想过了，在替换时，要实现旧新工作的交接，即要把旧模块的数据记录转换给新模块，以使新模块重绘内核内存图景。我们的目标：LINUX要傻瓜式组装，将有许多内存管理，进程管理，文件系统的插件可选，以适应自己具体情况的需要。
不过目前的目标：好好读核，不要空谈。（这两天学习有点冒进的苗头，书光想住后翻）
希望大家也在此谈谈你们的读核经验，以让象我这样的棒槌少走点弯路。
2003.04.21读核日记－－发现linux在初始化BUDDY算法的数据结构时很低效
今日读BUDDY内存分配算法，算法确实很不错，但LINUX在初始化BUDDY算法的数据结构时很低效。我先打个比喻：给你一个大碗，里面装满了大米，现在让你大米转移到
另一个碗里，你是把米从一个碗直接倒到另一个碗里，还是把米一粒一粒从一个碗放到另一个碗里？答案是明确的，直接倒。
而linux在初始化BUDDY算法的数据结构时却选择了类似把米从一个碗一粒一粒放到另一个碗里方法。
好了，看看系统是如何初始化BUDDY算法的数据结构的。
BUDDY在回收页面时一般用free_pages(),free_page(),它们都要实现伙伴的合并。而且最多9－order次合并。
在mem_init()中，通过对所有的动态内存进行逐页扫描，并调用free_page()来把空页一页一页的插入BUDDY中。
事实上，动态内存就那么几大块，所以完全可以用一个递归函数用很少的
次数就可完成工作。
我写了一个：
buddy_init( start_addr,end_addr, order)
//start_addr,end_addr为要释放的内存块首尾,order为要插入的BUDDY槽号
{unsigned long mask=(~0ul)<<order; //生成以order为边界的掩码
page * start,end; //中间以order为边界的大块的首尾地址
if(order==0)
{free_page(start_addr); return; } //递归出口，即只有一页要求释放
//求出start,end;
start=(start_addr+(1<<order)-1)&mask;
end= end_addr&mask;
for(tmp=start,tmp<end,tmp+=1<<order)
{free_pages(tmp,order); //中间以order为边界的大块的释放
}
if(start_addr!=start) //若相等，则说明没有左零头，不用再递归
buddy_init(start_addr,start,order-1);
if(end_addr!=end) //若相等，则说明没有右零头，不用再递归
buddy_init(end,end_addr,order-1);
｝
函数写的不严密，但其思想是尽量用free_pages()来大块大块的插入，
因为这样一次最多可释放512页，比一页一页效率高多了。
2003.4.21读核日记更正
因为是先写到记事本里，再粘上来，但不知为什么数据没粘全，所以再粘一遍很抱歉
今日读BUDDY内存分配算法，算法确实很不错，但LINUX在初始化BUDDY算法的数据结构时很低效。
我先打个比喻：给你一个大碗，里面装满了大米，现在让你大米转移到
另一个碗里，你是把米从一个碗直接倒到另一个碗里，还是把米一粒一粒从一个碗放到另一个碗里？答案是明确的，直接倒。
而linux在初始化BUDDY算法的数据结构时却选择了类似把米从一个碗一粒一粒放到另一个碗里方法。
好了，看看系统是如何初始化BUDDY算法的数据结构的。
BUDDY在回收页面时一般用free_pages(),free_page(),它们都要实现伙伴的合并。而且最多9－order次合并。
在mem_init()中，通过对所有的动态内存进行逐页扫描，并调用free_page()来把空页一页一页的插入BUDDY中。
事实上，动态内存就那么几大块，所以完全可以用一个递归函数用很少的
次数就可完成工作。
我写了一个：
buddy_init( start_addr,end_addr, order)
//start_addr,end_addr为要释放的内存块首尾,order为要插入的BUDDY槽号
{unsigned long mask=(~0ul)<<order; //生成以order为边界的掩码
page * start,end; //中间以order为边界的大块的首尾地址
if(order==0)
{free_page(start_addr); return; } //递归出口，即只有一页要求释放
//求出start,end;
start=(start_addr+(1<<order)-1)&mask;
end= end_addr&mask;
for(tmp=start;tmp<end;tmp+=(1<<order))
{free_pages(tmp,order); //中间以order为边界的大块的释放
}
if(start_addr!=start) //若相等，则说明没有左零头，不用再递归
buddy_init(start_addr,start,order-1);
if(end_addr!=end) //若相等，则说明没有右零头，不用再递归
buddy_init(end,end_addr,order-1);
｝
函数写的不严密，但其思想是尽量用free_pages()来大块大块的释放，
因为这样一次最多可释放512页，比一页一页效率高多了。 我写得函数部分不知为什么贴出后总是显示不全，我在贴之前已经仔细检查过了，没有错的，真不可思议！！！
算了，可能也没人愿意读它。我只是写写我的读核感受而已 [Color=blue]我很久以前也看过buddy算法,也用它写过程序,只是没看过它的初始化的情况,只是好像有一点你没有注意(不知道是不是我记错了),例如你的start=(start_addr+(1"<<"order)-1)&mask;是不是应该在1"<<"order)后面来个PAGE_SHIFT,当然这是小事.至于你说的低效的问题.也许是.对了,你看过他的初始化程序,那么最初系统是不是全部按照order从9,8..开始往下排列.也就是先排9order的,零星的排8,再零星的排7...
ps:会不会是系统初始化的时候,怕某块物理内存坏了,造成内存空间的不连续性,所以要一页一页的插入合并阿?
ps2:你说的打不出某些程序,那是因为这个社区大概是为了安全或者别的编码之类的原因,把一些特殊字符解释错了吧,比如你在两个>之外加一对引号就能正常输入你的程序了.[/Color] blueflame:
还是你经验丰富呀，把没显示出来的东西看到了。
我现在也明白过来了：用查看源代码直接读此页的html文本，你是不是这样做的？
free_page()释放一页时，它会从order0开始，改相应的map标记，然后看能不能向上合并（就是通过map的相应位来判断其伙伴在不在），若不可以，它就插入order0，然后返回;若可以，它会和伙伴合并，再向order1里试插入，若还可以合并，则以此推，直到order9，才算结束。
所以若用free_page()初始化化BUDDY时，会发生大量的合并，（因为此时的动态内存是大块连续的，所以最后，除左右零头外，都是属于order9的块）
但若用free_pages(),则因为直接把order9的块分离出来插入order9，所以根本不存在合并现象.至于左右零头，它们会再分解，插入相应的槽中，也不会发生合并现象，因为试图合并，必然失败。
至于说是检查物理内存是否损坏，我想可以分离出来，不要因为要扫描每页物理内存，就“顺便”初始化BUDDY，总之，用free_page()代价太大，（不过确实很
省心，不用另写代码了）
2003.04.22读核日记－－slad算法的2.4内核版本更简洁了
今天读了＜＜深入理解linux内核＞＞(第一版，2.2内核）的slab分配器原理。书中讲的kmem_cache_t,kmem_slab_t原理都非常清楚，但一到
kmem_bufctl_t时，让人弄不清它到底如何同前两个结构配合。（当然，这不是作者的过，而是2.2版本对算法实现的不完美）。
最后，我不得不看源代码（2.4.18版本），发现对”对象描述符“的实现有了很大的改进：
1。若SLAB描述符在SLAB内部，它由2.2版本在SLAB的尾部改到首部，且后面紧跟对象描述符。
2。对象描述符原则上可在内部或外部，但linux只把它放在内部，不再放在外部，所以不用记录对象描述符的地址，通过kmem_cache_t,kmem_slab_t，及对象的地址便可算出对象描述符的地址，而且对象描述符的作用更加简单，只是把空对象链起来；已分配的对象的对象描述符没有什么作用了。
我为弄清它，还看了understanding linux kernel第2版，还有情景分析。发现情景分析基本上就是代码，所以讲的不好，书中只有两个图，图2.8画的是2.2版本的情况，图2.9则不知它要表达什么。所以我建议大家看buddy和slab算法时，看understanding linux kernel 第一版和第2版，比较着看，真是讲得很好，它中的图做的很精细，对理解算法很有帮助。
看看不同版本，想想linux的成长过程，不也是很有启发意义的吗？
对2003.04.22读核日记－－更正
昨天发了关于slab算法的帖子，晚上睡觉又想了想，发现有点问题，所以一大早就爬起来，又分析了源代码。所以做以下更正：
对象描述符在linux2.4中还是可内可外的，只是它和slab描述符如影随形。即它总是紧跟在slab描述符后面，因此，只要知道slab描述符的地址，便可算出对象描述符的地址。
总之，slab描述符在外，它就在外，slab描述符在内，它就在内；
当slab描述符在内时，放在slab区的开始处，即跟在着色区的后面。
当slab描述符在外时，因为不同的cache的slab区放的对象个数不同，所以一个slab所需要的对象描述符的个数是不同的，通过计算可得到“slab描述符加对象描述符数组”所需的内存大小，这便是分配slab描述符时的真正大小。所以在外的slab描述符可能分布在cache_sizes的不同cache中。
读核日记暂停
日记暂停原因：本人身处华南理工大学，但因为华工计算机专业偏向应用（计算机系统结构方向我认为名存实亡），所以感觉缺少至同道合者（或许有，但我不知），不法同别人充分交流感想体会（我认为一个充满学习交流的集体才是一个让人留恋的集体，华工就缺这种气氛，大部分人就只想就业和挣钱），所以发现本论坛后本想利用此版发表自已的读核感受和倾听大家的读核经验。
但发现除了问问题有人解答外，并无人跟贴读核的经验和教训。
所以有点失望.... [COlor=blue]何必灰心丧气呢.这里的气氛有点点沉闷,但是只要有时间就来这里发发心得吧.我现在想看网络部分,可是对者那么一大块内容,发呆了好几天,什么都没做成.[/Color] blueflame:
谢谢你的关心。其实过去的一个月我都在看linux，整天的看，有时也看得很烦，当烦的时候，我就下载一部电影看看，或睡上一觉，也就没什么了。
我把学习Linux分成三个阶段：第一阶段是从整体上把linux的各种重要数据结构
和各部分之间的关系及工作机理从思想上想通，再辅之以学习系统编程（我把它称为完成linux的总体设计）就目前来看，到下学期开学就可完成；第二阶段是把linux再从头到尾过一遍，主要完成源代码的分析（我把它称为物理设计）；我估计需2个月。第三阶段基本上就是不断跟踪Linux内核的发展，并有能力做一点修改。
请问你网络方面参考了什么书？
你打算怎么攻克它？
(笑也不争春，只把春来报，待到山花烂漫时，她在从中笑） [Color=blue]网络部分我没有参考书,我在网上找文章,比如Alan Cox写的Network Buffers and Memory Management等等.先看这些,再看源代码.可是一个令人沮丧的问题是,源代码发展太快,跟不上形式阿.[/Color]