【Linux】深入理解缓冲区

目录

什么是缓冲区

为什么要有缓冲区

缓冲区刷新策略

缓冲区在哪里

 手动设计一个用户层缓冲区


什么是缓冲区

缓冲区本质上一块内存区域,用来保存临时数据。缓冲区在各种计算任务中都广泛应用,包括输入/输出操作、网络通信、图像处理、音频处理等。

这块内存区域是由谁提供的呢,缓冲区在哪里呢?可以继续向下看.

这里先告诉答案,是C标准库提供的.

为什么要有缓冲区

缓冲区用于解决数据传输速度不匹配或不稳定的问题,并提高数据处理的效率。

当从硬盘读取大量数据时,将数据直接传输到内存中可能会导致读写速度不匹配(内存速度快,而硬盘读取速度慢,这是相对来说的),从而导致性能瓶颈。为了缓解这个问题,可以引入一个缓冲区,先将一部分数据读取到缓冲区中,然后再从缓冲区逐步读取数据到内存中,以平衡数据传输速度。

这里有个很合适的例子来解释:

例如你和你的朋友在两个不同的大学,相差大概500公里,有一天你想送一些书给你的朋友,此时你可以选择骑自行车,亲自骑行去送这些书,礼轻情意重嘛,加上中途休息,然后由于速度慢,花了大概一周的时间才到,送了之后然后又骑回自己的学校,又花了一周的时间,一共过了两周完整的工作才完成,耗时太长

假设此时你学聪明了,既然那么慢,那么直接坐高铁去送,可来回一共都500多了,这都比这些书的价值多了,即成本太高了.

可以把以上这些书看做资源,这种模式叫做写透模式.

此时你想到,可以寄快递来送这些书啊,价格便宜,而且两三天就到了,这多实惠,于是你把这些书交给了顺丰 快递,过了两三天,你的朋友在手机上给你说,说我收到这些书了,然后这样就成功的把资源交到了对方的手中。这个顺丰快递在这里扮演的角色便是缓冲区. 

顺丰 拿到你的快递也不是立马就送,而是等待数量足够多时,再一次性开始运输,这相当于是一种缓冲区的刷新策略.

缓冲区刷新策略

刷新策略主要有以下3种:

1.立即刷新

2.行刷新(行缓冲),遇到\n刷新

3.满刷新(全缓冲),指的是将输入或输出的数据完全存储在缓冲区中,然后再进行传输或处理。

当然也会有一些特殊情况:

1.用户强制刷新(fflush)

2.进程退出

遇到以上两种情况时,必须马上从刷新缓冲区的数据,而不要按照之前的刷新策略继续等待.

所以缓冲策略 = 一般情况 + 特殊情况.


一般而言,行缓冲的设备文件 --- 显示器

全缓冲的设备文件 --- 磁盘文件

所有的设备,永远倾向于全缓冲 --> 缓冲区满了再刷新 --> 需要更少次数的IO操作 -->更少次数的外设访问(相当于提高了整机效率).

有同学可能有疑问,比如10行数据,每一行有100个字节,虽然10行最后再一起刷新,只进行了一次的外设访问,但是数据量很多啊,1000个字节,而按行刷新虽然刷新了10次,但每次数据量少啊,那为什么外设访问次数越少越好呢?

这是因为和外部设备IO的时候,数据量的大小不是主要矛盾,你和外设预备IO的过程是最耗费时间的.

比如你和别人借钱,往往沟通的过程要耗费很长时间,而转账的过程只需要几秒,这同样的道理.

那我们直接改成全缓冲不就行了吗?这样效率不就高了吗,还要什么行缓冲.

其实这些策略,都是根据实际情况做的妥协:

例如行缓冲就是针对于显示器,是给用户看的,一方面要照顾效率,另一方面也要照顾用户体验.

而平常我们打开的一些文本文件便是全缓冲,等到用户全部写完再一次性进行保存.

有了这些缓冲区和策略,便可以提高数据处理的效率.

缓冲区在哪里

为了解决这个问题,我们可以先写以下代码:

int main()    
{    
    //C语言提供的接口    
    printf("hello,printf\n");    
    fprintf(stdout,"hello,fprintf\n");    
    const char* s = "hello,fputs\n";    
    fputs(s,stdout);    
    
    //系统接口    
    const char* ss = "hello,write\n";    
    write(1,ss,strlen(s));    
    //注意这里有一个创建子进程
    fork();  
}

我们这里把创建子进程fork函数放在了最后,这有什么用呢?放在最后子进程什么都没有执行就结束了,有什么意义呢?

我们先把代码运行一下:

 可以看到,这些都是正常输出的,没有任何问题.

但我们此时创建一个log.txt文件,然后把输出结果重定向到它里面,然后cat看卡里面的内容:

很奇怪的现象:我们发现除了系统接口的只输出了一次C语言提供的函数都输出了两次 .

这是什么原因呢?


根据我们上面所讲的缓冲区的刷新策略:

我们直接运行程序是向显示器中打印,采用的是行刷新策略,而我们重定向到文件中,向文件中打印,便成了全缓冲策略.

1.如果是向显示器中打印,那么采用的是行刷新策略,那么最后执行fork的时候,所有的数据都已经刷新完成了,此时再执行fork就没有意义了.

2.如果对程序进行了重定向,即此时要向文件中打印,此时刷新策略便隐式的变成了全缓冲

\n换行符便没有了意义.

fork的时候,一定是函数已经执行完了,但是数据还没有刷新! 这些数据在当前进程对应的C标准库中的缓冲区里. 这些数据是父进程的.

代码执行完了,并不代表数据已经刷新了,fork之后子进程和父进程执行return 0的时候,即要把数据刷新的时候,要发生写时拷贝,这样就有了两份数据,然后分别输出到文件中。

所以就出现了C语言标准库输出的函数打印了两次,而系统接口打印了一次。

因为系统接口是直接写入到了文件中,而不用经过缓冲区。

此时,更加让我们确信了一个事实缓冲区一定不是操作系统提供的而是由C语言标准库提供的!因为如果是操作系统提供的,那么这个系统接口也应该输出两次,而不是只有一次。


那么它在哪里呢?

我们再加一条代码:

    fflush(stdout);

 我们再次运行,然后将其输出到log.txt文件中:

我们发现此时都只输出了一条语句,而不是两条语句了. 

经过上面的讲解,我相信大家也能明白了,fflush已经强制将缓冲区的内容刷新了出来,此时缓冲区已经是空的了,然后再执行fork,父子进程缓冲区都是空的,所以也没有数据刷新了,这样才各自只打印了一条语句。

那么注意的是,我们fflush是C语言提供的,参数我们只提供了一个stdout,那么它是如何找到缓冲区的呢?

在C语言中,打开文件对应函数是fopen.它的函数原型如下:

它的函数返回值是FILE*,即一个struct file,里面不仅封装了fd,而且包含了该文件fd对应的语言层的缓冲区结构_IO_FILE。

_IO_FILE的内部结构大致如下:

 

 所以C语言缓冲区存在FILE结构体里.

这里需要说明一下的是,内核中也有缓冲区,只不过是内核缓冲区,和用户级缓冲区(例如C语言提供的缓冲区)两个各自独立,互不影响.

 手动设计一个用户层缓冲区

我们知道缓冲区被封装在一个file结构体中,而且里面还有文件描述符fd等,所以首先我们要创建一个结构体来封装这些数据.

#define NUM 1024                                                                                                                      
struct MyFILE_{    
 int fd;//文件描述符
 char buffer[NUM];//缓冲区
 int end;//当前缓冲区的结尾    
};    
typedef struct MyFILE_ MyFILE;    

同样的,为了使用,还有四个接口来使用,分别为fopen_,fputs_,fflush_,fclose_这四个接口。

先来说fopen_,这个主要有两个参数,第一个参数是打开的文件路径pathname,第二个是打开模式mode(r,r+,w,w+,a,a+),最后返回MyFILE结构体.

这六种模式不全部一一写,只写一种w模式,够我们使用即可。

方法思路是:首先调用系统open()接口,然后传入参数,打开模式为O_WRONLY,O_TRUNC,O_CREAT,然后接受返回的fd

如果fd大于等于0,说明打开成,然后此时再为FILE结构体开空间并初始化,并将FILE中的fd等于刚才open所得到的fd

MyFILE* fopen_(const char* pathname,const char* mode)
{
  assert(pathname);
  assert(mode);
  
  MyFILE* fp = NULL;
  if(strcmp(mode,"r") == 0)
  {

  }
  else if(strcmp(mode,"r+") == 0)
  {

  }
  else if(strcmp(mode,"w") == 0)
  {
    int fd = open(pathname,O_WRONLY | O_TRUNC | O_CREAT,0666);
    if(fd >= 0)
    {
      fp = (MyFILE*)malloc(sizeof(MyFILE));
      memset(fp,0,sizeof(MyFILE));
      fp->fd = fd;

    }
    
  }
  else if(strcmp(mode,"w+") == 0)
  {

  }
  else if(strcmp(mode,"a") == 0)
  {

  }
  else if(strcmp(mode,"a+") == 0)
  {

  }
  return fp;
}

接下来是fputs_,主要作用是向指定文件描述符fd中(本质上还是向缓冲区中写入)写入内容。所以第一个参数是要写入的内容,第二个参数是MyFILE结构体.

主要思路是先将传入的内容拷贝到MyFILE中的buffer缓冲区中,然后再更新end的长度。

此时我们再判断fd是0,1,2还是其他文件,这里我们只实现了fd=1的情况

当fd=1时,先判断缓冲区中最后一个字符是否是'\0',如果是,则write写入到1中,即刷新缓冲区的内容,并将end置为0.

若不是,则无需任何操作.

void fputs_(const char* message, MyFILE* fp)
{
  assert(message);
  assert(fp);

  strcpy(fp->buffer+fp->end,message);                                                                                                 
  fp->end += strlen(message);

  //for debug
  //printf("%s\n",fp->buffer);
  //暂时没有刷新,刷新策略是是来执行的呢? 用户通过执行C标准库中的代码逻辑,来完成刷新动作
  //效率提高体现在哪里呢?因为C提供了缓冲区,那么我们就通过策略,减少了IO次数的执行次数,不是数据量!
  if(fp->fd == 0)
  {
    //标准输入
  }
  else if(fp->fd == 1)
  {
    //标准输出
    if(fp->buffer[fp->end-1] == '\n')
    {
      //fprintf(stderr,"fflush: %s",fp->buffer);
      write(fp->fd,fp->buffer,fp->end);
      fp->end = 0;
    }
  }
  else if(fp->fd == 0)
  {
    //标准错误
  }
  else
  {
    //其他文件
  }
}

接下来是fflush_,这个函数主要作用是强制刷新缓冲区中的内容.

主要思路是:先判断缓冲区内容是否为空,若不为空,则write写入到编号为fd文件中,然后调用syncfs函数将数据写入磁盘,最后将end置为0.

void fflush_(MyFILE* fp)
{
  assert(fp);
  if(fp->end != 0)
  {
    //暂且认为刷新了 -- 其实是把数据写到了内核
    write(fp->fd,fp->buffer,fp->end);
    syncfs(fp->fd);//将数据写入到磁盘
    fp->end = 0;
  }
}

最后一个是fclose_,这个函数作用是关闭文件,并刷新缓冲区内容.

这个比较简单,直接复用刚才的fflush_刷新缓冲区和调用close函数关闭文件即可

void fclose_(MyFILE* fp)
{
  assert(fp);
  fflush_(fp);
  close(fp->fd);
  free(fp);

}

 关于缓冲区的内容到这里就讲解完了,如果有疑问或者错误的地方,欢迎评论区或私信 提出或指正哦

  • 11
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 8
    评论
内容简介   本书从只有二十行的引导扇区代码出发,一步一步地向读者呈现一个操作系统框架的完成过程。书中不仅关注代码本身,同时关注完成这些代码的思路和过程。本书不同于其他的理论型书籍,而是提供给读者一个动手实践的路线图。读者可以根据路线图逐步完成各部分的功能,从而避免了一开始就面对整个操作系统数万行代码时的迷茫和挫败感。书中讲解了大量在开发操作系统中需注意的细节问题,这些细节不仅能使读者更深刻地认识操作系统的核心原理,而且使整个开发过程少走弯路。本书分上下两篇,共11章。其中每一章都以前一章的工作成果为基础,实现一项新的功能。而在章的内部,一项大的功能被分解成许多小的步骤,通过完成每个小的步骤,读者可以不断获得阶段性的成果,从而让整个开发过程变得轻松并且有趣。   本书适合各类程序员、程序开发爱好者阅读,也可作为高等院校操作系统课程的实践参考书。 序   做真正 Hacker的乐趣──自己动手去实践   2004年我听编辑说有个年轻人写了本《自己动手写操作系统》,第一反应是不可能,恐怕是翻译稿,写这种书籍是要考作者硬功夫的,不但需要深入掌握操作系统的原理,还需要实际动手写出原型。   历史上的 Linux就是这么产生的,Linus Torvalds当时是一名赫尔辛基大学计算机科学系的二年级学生,经常要用自己的电脑去访问大学主机上的新闻组和邮件,为了方便读写和下载文件,他自己编写了磁盘驱动程序和文件系统,这成为了 Linux第一个内核的雏形。   我想中国有能力写出内核原型的程序员应该也有,但把这个题目写成一本书,感觉上不会有人愿意做这件事情,作者要花很多时间,加上主题比较硬,销售量不会太高,经济上回报有限。   但拿来文稿一看,整个编辑部大为惊艳,内容文笔俱佳,而且绝对原创,马上决定在《程序员》连载。2005年博文视点出版的第一版也广受好评。   不过有很多读者还是质疑:现在软件编程主要领域是框架和应用,还需要了解操作系统底层吗?   经过四年的磨练成长,于渊又拿出第二版的书稿《Orange'S:一个操作系统的实现》,这本书是属于真正 Hacker的。我虽然已经有多年不写代码了,但看这本书的时候,让我又重新感受到做程序员的乐趣:用代码建设属于自己的系统,让电脑听从自己的指令,对系统的每个部分都了如指掌。   黑客(hacker)实际是褒义词,维基百科的解释是喜欢用智力通过创造性方法来挑战脑力极限的人,特别是他们所感兴趣的领域,例如软件编程或电气工程。个人电脑、软件和互联网等划时代的产品都是黑客创造出来的,如苹果的 Apple电脑、微软的 Basic解释器、互联网的 Mosaic浏览器。   回答前面读者的质疑,学软件编程并不需要看这本书,想成为优秀程序员和黑客的朋友,我强烈建议你花时间来阅读这本书,并亲自动手实践。正如于渊在本书结尾中所说“我们写自己的操作系统是出于一种好奇,或者说一种求知欲。我希望这样不停地‘过把瘾’能让这种好奇不停地延续”。   好奇心是动力的源泉,追究问题的本质是优秀黑客的必备素质,只有充分掌握了系统原理,才能在技术上游刃有余,才能有真正的创新和发展。中国需要更多真正的黑客,也希望更多的程序员能享受属于黑客的创造乐趣。   蒋涛   2009年 4月 作者自序   本书是《自己动手写操作系统》的第二版,通过一个具体的实例向读者呈现一个操作系统雏形的实现过程。有关操作系统的书籍资料可以找到很多,但是关注如何帮助读者实现一个试验性操作系统的书籍却不多见,本书便是从一个简单的引导扇区开始,讲述一个操作系统成长的故事,以作读者参考之用。   本书面向实践,通过具体实例教读者开发自己的操作系统。书中的步骤遵循由小到大、由浅入深的顺序,跟随这些步骤,读者可以由一个最简单的引导扇区开始,逐渐完善代码,扩充功能,最后形成一个小的操作系统。   本书不仅介绍操作系统的各要素,同时涉及开发操作系统需要的各个方面,比如如何建立开发环境、如何调试以及如何在虚拟机中运行等。书中的实例操作系统采用IA32作为默认平台,所以保护模式也作为必备知识储备收入书中,而这是传统的操作系统实践书籍经常忽略的。总之,只要是开发自己的操作系统中需要的知识,书中都尽量涉及,以便于读者参考。   众所周知,一个成型的操作系统往往非常复杂。如果考虑到操作系统作为软硬件桥梁的特殊地位,那么它可能看上去比一般的软件系统更难理解,因为其核心部分往往包含许多直接针对CPU、内存和 I/O端口的操作,它们夹杂在一片代码汪洋之中,显得更加晦涩。   我们有许多源代码公开的操作系统,可供随时下载和阅读,看上去好像让实现一个供自己把玩的微型操作系统变得容易很多,但事实往往不尽人意,因为这些代码动辄上万甚至几十几百万行,而且细节之间经常互相关联,要理解它们着实不易。我们有许多容易得到的操作系统教程,但读来好像总觉得跟我们有隔膜,不亲近。造成这些的根本原因,在于学习者一开始就面对一个完整的操作系统,或者面对前辈们积累了几十年的一系列理论成果。而无论作者多么擅长写作,读者多么聪明,或者代码多么优秀,要一个初学者理清其中的头绪都将是非常困难的。   我并非在此危言耸听,因为这曾经是我的亲身体会。当然,如果只是为了考试,几本操作系统理论书籍就足够了,你不需要对细节那么清楚。但如果是出于兴趣呢?如果你是想编写自己的操作系统呢?你会发现理论书籍好像一下子变得无用武之地,你会发现任何一个细节上的理解错误都可能导致自己辛辛苦苦编写的代码运行异常甚至崩溃。   我经历过这一切!我曾经翻遍了一本《操作系统:设计与实现》,也没有找到实现一个操作系统应该从何处着手。并不是这些书不好,也不是前人的代码不优秀,而是作为一无所知的初学者,我们所不了解的不仅是高居庙堂的理论知识,还有让我们举步维艰的实践细节。   可能在这些教科书作者的眼里,操作的细节不属于课程的一部分,或者这些细节看上去太容易,根本不值一提,甚至作者认为这些属于所谓“经验”的一部分,约定俗成是由读者本人去摸索的。但是实际情况往往是,这些书中忽略掉的内容恰恰占去了一个初学者大部分的时间,甚至影响了学习的热情。   我至今仍记得当我开始编写自己的操作系统时所遭受的挫败感,那是一种不知道如何着手的无助的感觉。还好我坚持了下来,克服了各种困难,并完成了自己的操作系统雏形。   进而我想到,一定不只是我一个人对编写自己的操作系统怀有兴趣,也一定不只是我一个人在实践时遇到困难。或许我应该把自己的经历写下来,从而可以帮助跟我相似的后来者,就这样,我编写了本书的第一版,也就是《自己动手写操作系统》。我相信,如果你也对神奇的计算机世界充满好奇,并且希望通过自己编写操作系统的方式来了解背后发生的故事,那么你一定可以在这本书中得到一些帮助。而假如你真的因为我的书而重新燃起实践的热情,从而开始一段操作系统旅程,我将会感到非常高兴。   不过我得坦白,在写作《自己动手写操作系统》的时候,我并不敢期待它能引起多少反响,一方面因为操作系统并不是时尚的话题,另一方面我也是走在学习的路上,或许只是比读者早走了一小步而已。然而出乎我的意料,它面世后重印多次,甚至一度登上销量排行榜的榜首,这让我觉得它的确有一定的参考价值,我要借此机会感谢所有支持我的读者。   在我写作《自己动手写操作系统》的时候,并没有想过今天会有一个第二版。原因在于,我希望这本书是用来填补空白的,而不是重复去做别人已经做得很好的事情。所谓填补空白,具体说就是让像我一样的操作系统爱好者在读完本书之后,能够有信心去读其他比较流行的开源的操作系统代码,有能力从零开始自己动手写操作系统,而这个任务第一版已经完成了。   那么为什么我又写作了第二版呢?原因有几个方面。第一,虽然第一版未曾涉及的进程间通信、文件系统等内容在许多书中都有讲解,但阅读的时候还是感觉有语焉不详的通病,作者本人可能很清楚原委,但写得太简略,以至于读者看来未必清晰。第二,我自己想把这个圈画圆。第一版的书虽然完成了它的使命,但毕竟到书的结尾,读者看到的不是一个真正的操作系统,它没有文件系统,没有内存管理,什么也干不了。在第二版中,你将会看到,你已经可以通过交叉编译的方式为我们的实验性 OS编写应用程序了,也就是说,它已经具备操作系统的基本功能,虽然仍然极其简陋,但第一个圈,毕竟是已经圆起来了。第三,实践类的操作系统书籍还是太少了,以至于你要想看看别人是怎么做的,除了读以《操作系统:设计与实现》为代表的极少数书籍之外,就是一头扎进源代码中,而结果有时相当令人气馁。我自己也气馁过,所以我在第二版中,仍然试图把话说细一点,把自己的经验拿出来分享。而且我选择我能想到的最精简的设计,以便让读者不至于陷入太多细节而无法看到全貌。我想这是本书可能具有的价值所在──简化的易懂的设计,还有尽量详细的文字。   在这一版中,内容被划分成上下两篇。上篇基本上是第一版的修订,只是做了一个调整,那便是在兼顾 Windows和Linux两方面用户的基础上,默认在Linux下建立开发环境来编写我们的操作系统。至于这样做的原因,在本书第 2章有比较详细的说明。当然,开发环境毕竟是第二位的,书中讲述的内容以及涉及的代码跟第一版都是一致的。本书的下篇全部都是新鲜内容,主要是增加了进程间通信、文件系统和内存管理。跟第一版的做法相同,下篇仍然不仅关注结果,更加致力于将形成一个结果的过程呈现出来。与此同时,由于本书旨在分享和引路,所以尽可能地简化了设计,以便将最重要的部分凸显出来。读者将看到,一个操作系统的文件系统和内存管理可以简陋到什么程度。简陋不是缺点,对于我们初学者而言,正是需要从简陋入手。换言之,如果你已经对实现一个操作系统有了一定的经验,那么这本书可能不适合你。这本书适合从来没有编写过操作系统的初学者。   本书的排版是我用L ATEX自己完成的。在排版中我花了一些工夫,因为我希望读者购买的首先是一本易于阅读且赏心悦目的书,其次才是编写操作系统的方法。另外,书中列出的代码均由我自己编写的程序自动嵌入L ATEX源文件,从而严格保证书和光盘的一致性,读者可以根据文件名和行号方便地找到光盘中   代码的准确位置。   此外,在第二版中还有一些小的变化。首先是操作系统的名字改变了,原因在于虽然我们的试验性   OS从前辈们那里借鉴了很多东西,但其各个部分的设计(比如文件系统和内存管理)往往有其独特之处,所以我将原先的 Tinix(本意为 TryMinix)改成了新名字Orange ’S(这个名字来自于我的妻子 ,),以表示它们的不同。另外,书中的代码风格,有些地方也做了调整。   我想,虽然第二版有着这样那样的变化,但有一点没有变,那就是本书试图将我在编写自己操作系统的过程中的经验尽可能地告诉读者,同时尽可能将我当初的思路和编码过程呈现出来。很可能读者比我更聪明,有更好的解决问题的方法,但无论如何,我认为我自己的经验可以为读者所借鉴。如果真是如   此,我将会非常欣慰。   在第二版的编写过程中,我同样要感谢许多人。感谢我的父母和爷爷对我的爱,并希望爷爷不要为我担心,写书是件辛苦的事,但同时也使我收获良多。爸爸在第二版的最后阶段帮我订正文字,这本书里有你的功劳。我要感谢博文视点的各位朋友,感谢郭老师的理解和支持,感谢李玲的辛勤工作,感谢江立和李冰,你们的高效让我非常钦佩。我还要感谢孟岩老师,你给我的鼓励我一直记在心里。我要感谢我的挚友郭洪桥,不仅仅因为你在技术上给我的帮助,更加因为你在精神上给我的支持。感谢我的同事和朋友张会昌,你在技术上的广度和深度总令我钦佩。另外,在第一版中帮助我的人,我要再次谢谢你们,因为没有第一版,也就没有第二版。   在所有人中我最应该感谢和最想感谢的,是我的妻子黄丹红,感谢你给我的所有建议,还有你帮我画的图。尤其是,当这本书在我预想的时间内没有完成的时候,当我遇到困难迟迟不能解决的时候,你总在一旁给我鼓励,在你那里,我从来都能感觉到一种温暖,我深知,如果没有你的支持,我无法坚持下来将书写完。谢谢你,这本书同样属于你。   跟第一版相比,这本书涉及的内容触及操作系统设计的更多方面,而由于笔者的水平实在有限,难免有纰漏甚至错误。如果读者有任何的问题、意见或建议,请登录http://www.osfromscratch.org,让我们共同探讨,共同进步。   本书导读   这本书适合谁   本书是一本操作系统实践的技术书籍。对于操作系统技术感兴趣,想要亲身体验编写操作系统过程的实践主义者,以及Minix、Linux源代码爱好者,都可以在本书中得到实践中所需的知识和思路。   本书以“动手写”为指导思想,只要是跟“动手写”操作系统有关的知识,都作为介绍对象加以讨论,所以,从开发环境的搭建,到保护模式,再到IBMPC中有关芯片的知识,最后到操作系统本身的设计实现,都能在本文中找到相应介绍。所以如果你也想亲身实践的话,本书可以省去你在书店和互联网寻找相应资料的过程,使你的学习过程事半功倍。在读完本书后,你不但可以获得对于操作系统初步的感性认识,并且对 IBMPC的接口、IA架构之保护模式,以及操作系统整体上的框架都将会有一定程度的了解。   笔者相信,当你读完本书之后,如果再读那些纯理论性的操作系统书籍,所获得的体验将会完全不同,因为那些对你而言不再是海市蜃楼。   对于想阅读 Linux源代码的操作系统爱好者,本书可以提供阅读前所必要的知识储备,而这些知识储备不但在本书中有完整的涉及,而且在很多 Linux书籍中是没有提到的。   特别要提到的是,对于想通过阅读 Andrew S. Tanenbaum和 Albert S. Woodhull的《操作系统:设计与实现》来学习操作系统的读者,本书尤其适合作为你的引路书籍,因为它翔实地介绍了初学者入门时所必需的知识积累,而这些知识在《操作系统:设计与实现》一书中是没有涉及的,笔者本人是把这本书作为写操作系统的主要参考书籍之一,所以在本书中对它多有借鉴。   你需要什么技术基础   在本书中所用到的计算机语言只有两种:汇编和 C语言。所以只要你具备汇编和 C语言的经验,就可以阅读本书。除对操作系统常识性的了解(比如知道中断、进程等概念)之外,本书不假定读者具备其他任何经验。   如果你学习过操作系统的理论课程,你会发现本书是对于理论的吻合和补充。它是从实践的角度为你展现一幅操作系统画面。   书中涉及了 Intel CPU保护模式、Linux命令等内容,到时候会有尽可能清晰的讲解,如果笔者认为某些内容可以通过其他教材系统学习,会在书中加以说明。   另外,本书只涉及 Intel x86平台。   统一思想——让我们在这些方面达成共识   道篇   让我们有效而愉快地学习   你大概依然记得在你亲自敲出第一个“Hello world”程序并运行成功时的喜悦,那样的成就感助燃了你对编写程序浓厚的兴趣。随后你不断地学习,每学到新的语法都迫不及待地在计算机上调试运行,在调试的过程中克服困难,学到新知,并获得新的成就感。   可现在请你设想一下,假如课程不是这样的安排,而是先试图告诉你所有的语法,中间没有任何实践的机会,试问这样的课程你能接受吗?我猜你唯一的感受将是索然寡味。   原因何在?只是因为你不再有因为不断实践而获得的源源不断的成就感。而成就感是学习过程中快乐的源泉,没有了成就感,学习的愉快程度将大打折扣,效果于是也将变得不容乐观。   每个人都希望有效而且愉快的学习过程,可不幸的是,我们见到的操作系统课程十之八九令我们失望,作者喋喋不休地讲述着进程管理存储管理I/O控制调度算法,可我们到头来也没有一点的感性认识。我们好像已经理解却又好像一无所知。很明显,没有成就感,一点也没有。笔者痛恨这样的学习过程,也决不会重蹈这样的覆辙,让读者获得成就感将是本书的灵魂。   其实这本书完全可以称作一本回忆录,记载了笔者从开始不知道保护模式为何物到最终形成一个小小   OS的过程,这样的回忆录性质保证了章节的安排完全遵从操作的时间顺序,于是也就保证了每一步的可操作性,毫无疑问,顺着这样的思路走下来,每一章的成果都需要努力但又尽在眼前,步步为营是我   们的战术,成就感是我们的宗旨。   我们将从二十行代码开始,让我们最简单的操作系统婴儿慢慢长大,变成一个翩翩少年,而其中的每一步,你都可以在书中的指导下自己完成,不仅仅是看到,而是自己做到!你将在不断的实践中获得不断的成就感,笔者真心希望在阅读本书的过程中,你的学习过程可以变得愉快而有效。   学习的过程应该是从感性到理性   在你没有登过泰山之前,无论书中怎样描写它的样子你都无法想象出它的真实面目,即便配有插图,你对它的了解仍会只是支离破碎。毫无疑问,一千本对泰山描述的书都比不上你一次登山的经历。文学家的描述可能是华丽而优美的,可这样的描述最终产生的效果可能是你非去亲自登泰山不可。反过来想呢,假如你已经登过泰山,这样的经历产生的效果会是你想读尽天下描述泰山的书而后快吗?可能事实恰恰相反,你可能再也不想去看那些文字描述。   是啊,再好的讲述,又哪比得上亲身的体验?人们的认知规律本来如此,有了感性的认识,才能上升为理性的理论。反其道而行之只能是事倍功半。   如果操作系统是一座这样的大山,本书愿做你的导游,引领你进入它的门径。传统的操作系统书籍仅仅是给你讲述这座大山的故事,你只是在听讲,并没有身临其境,而随着这本书亲身体验,则好像置身于山门之内,你不但可以看见眼前的每一个细节,更是具有了走完整座大山的信心。   值得说明的是,本书旨在引路,不会带领你走完整座大山,但是有兴趣的读者完全可以在本书最终形成的框架的基础上容易地实现其他操作系统书籍中讲到的各种原理和算法,从而对操作系统有个从感性到理性的清醒认识。   暂时的错误并不可怕   当我们对一件事情的全貌没有很好理解的时候,很可能会对某一部分产生理解上的误差,这就是所谓的断章取义。很多时候断章取义是难免的,但是,在不断学习的过程中,我们会逐渐看到更多,了解更多,对原先事物的认识也会变得深刻甚至不同。   对于操作系统这样复杂的东西来说,要想了解所有的细节无疑是非常困难的,所以在实践的过程中,可能在很多地方,会有一些误解发生。这都没有关系,随着了解的深入,这些误解总会得到澄清,到时你会发现,自己对某一方面已经非常熟悉了,这时的成就感,一定会让你感到非常愉悦。   本书内容的安排遵从的是代码编写的时间顺序,它更像是一本开发日记,所以在书中一些中间过程不完美的产物被有意保留了下来,并会在以后的章节中对它们进行修改和完善,因为笔者认为,一些精妙的东西背后,一定隐藏着很多中间的产物,一个伟大的发现在很多情况下可能不是天才们刹那间的灵光一闪,背后也一定有着我们没有看到的不伟大甚至是谬误。笔者很想追寻前辈们的脚步,重寻他们当日的足迹。做到这一点无疑很难,但即便无法做到,只要能引起读者的一点思索,也是本书莫大的幸事。   挡住了去路的,往往不是大树,而是小藤   如果不是亲身去做,你可能永远都不知道,困难是什么。   就好像你买了一台功能超全的微波炉回家,研究完了整本说明书,踌躇满志想要烹饪的时候,却突然发现家里的油盐已经用完。而当时已经是晚上十一点,所有的商店都已经关门,你气急败坏,简直想摸起铁勺砸向无辜的微波炉。   研究说明书是没有错的,但是在没开始之前,你永远都想不到让你无法烹饪的原因居然是十块钱一瓶的油和一块钱一袋的更加微不足道的盐。你还以为困难是微波炉面板上密密麻麻的控制键盘。   其实做其他事情也是一样的,比如写一个操作系统,即便一个很小的可能受理论家们讥笑的操作系统雏形,仍然可能遇到一大堆你没有想过的问题,而这些问题在传统的操作系统书籍中根本没有提到。所以唯一的办法,便是亲自去做,只有实践了,才知道是怎么回事。   术篇   用到什么再学什么   我们不是在考试,我们只是在为了自己的志趣而努力,所以就让我们忠于自己的喜好吧,不必为了考试而看完所有的章节,无论那是多么的乏味。让我们马上投入实践,遇到问题再图解决的办法。笔者非常推崇这样的学习方法:   实践 →遇到问题 →解决问题 →再实践   因为我们知道我们为什么学习,所以我们才会非常投入;由于我们知道我们的目标是解决什么问题,所以我们才会非常专注;由于我们在实践中学习,所以我们才会非常高效。而最有趣的是,最终你会发现你并没有因为选择这样的学习方法而少学到什么,相反,你会发现你用更少的时间学到更多的东西,并且格外的扎实。   只要用心,就没有学不会的东西   笔者还清楚地记得刚刚下载完 Intel Architecture Software Developer Manual那三个可怕的 PDF文件时的心情,那时心里暗暗嘀咕,什么时候才能把这些东西读懂啊!可是突然有一天,当这些东西真的已经被基本读完的时候,我想起当初的畏惧,时间其实并没有过去多少。   所有的道理都是相通的,没有什么真正可怕,尤其是,我们所做的并非创造性的工作,所有的问题前人都曾经解决,所以我们更是无所畏惧,更何况我们不仅有书店,而且有互联网,动动手脚就能找到需要的资料,我们只要认真研究就够了。   所以当遇到困难时,请静下心来,慢慢研究,因为只要用心,就没有学不会的东西。   适当地囫囵吞枣   如果囫囵吞枣仅仅是学习的一个过程而非终点,那么它并不一定就是坏事。大家都应该听说过鲁迅先生学习英语的故事,他建议在阅读的过程中遇到不懂的内容可以忽略,等到过一段时间之后,这些问题会自然解决。   在本书中,有时候可能先列出一段代码,告诉你它能完成什么,这时你也可以大致读过,因为下面会有对它详细的解释。第一遍读它的时候,你只要了解大概就够了。    本书的原则   1.宁可啰嗦一点,也不肯漏掉细节   在书中的有些地方,你可能觉得有些很“简单”的问题都被列了出来,甚至显得有些啰嗦,但笔者宁可让内容写得啰嗦点,因为笔者自己在读书的时候有一个体验,就是有时候一个问题怎么也想不通,经过很长时间终于弄明白的时候才发现原来是那么“简单”。可能作者认为它足够简单以至于可以跳过不提,但读者未必那么幸运一下子就弄清楚。   不过本书到后面的章节,如果涉及的细节是前面章节提到过的,就有意地略过了。举个非常简单的例子,开始时本书会提醒读者增加一个源文件之后不要忘记修改Makefile,到后来就假定读者已经熟悉了这个步骤,可能就不再提及了。   2.努力做到平易近人   笔者更喜欢把本书称作一本笔记或者学习日志,不仅仅是因为它基本是真实的学习过程的再现,而且笔者不想让它有任何居高临下甚至是晦涩神秘的感觉。如果有一个地方你觉得书中没有说清楚以至于你没有弄明白,请你告诉我,我会在以后做出改进。 3.代码注重可读性但不注重效率   本书的代码力求简单易懂,在此过程中很少考虑运行的效率。一方面因为书中的代码仅仅供学习之用,暂时并不考虑实际用途;另一方面笔者认为当我们对操作系统足够了解之后再考虑效率的问题也不迟。   本书附带光盘说明   本书附带光盘中有本书用到的所有源代码。值得一提的是,其中不止包含完整的操作系统代码,还包含各个步骤的中间产物。换句话说,开发中每一步骤的代码,都可在光盘中单独文件夹中找到。举例说明,书的开篇介绍引导扇区,读者在相应文件夹中就只看到引导扇区的代码;第 9章介绍文件系统,在相应文件夹中就不会包含第 10章内存管理的代码。在任何一个步骤对应的文件夹中,都包含一个完整可编译运行的代码树,以方便读者试验之用。这样在学习的任何一个阶段,读者都可彻底了解阶段性成果,且不必担心受到自己还未学习的内容的影响,从而使学习不留死角。   在书的正文中引用的代码会标注出出自哪个文件。以“chapter5/b/bar.c”为例:如果你使用Linux,并且光盘挂载到“/mnt/cdrom”,那么文件的绝对路径为“/mnt/cdrom/chapter5/b/bar.c”;如果你使用Windows,并且光盘是 X:盘,那么文件的绝对路径为“X:nchapter5nbnbar.c”。 目 录   上 篇   第1章 马上动手写一个最小的“操作系统” 2   1.1 准备工作 2   1.2 十分钟完成的操作系统 3   1.3 引导扇区 4   1.4 代码解释 4   1.5 水面下的冰山 6   1.6 回顾 7   第2章 搭建你的工作环境 8   2.1 虚拟计算机Bochs 8   2.1.1 Bochs初体验 8   2.1.2 Bochs的安装 9   2.1.3 Bochs的使用 10   2.1.4 用Bochs调试操作系统 12   2.2 QEMU 15   2.3 平台之争:Windows还是*nix 16   2.4 GNU/Linux下的开发环境 20   2.5 Windows下的开发环境 22   2.6 总结 23   第3章 保护模式(Protect Mode) 25   3.1 认识保护模式 25   3.1.1 保护模式的运行环境 29   3.1.2 GDT(Global Descriptor Table) 31   3.1.3 实模式到保护模式,不一般的jmp 33   3.1.4 描述符属性 35   3.2 保护模式进阶 38   3.2.1 海阔凭鱼跃 38   3.2.2 LDT(Local Descriptor Table) 44   3.2.3 特权级概述 48   3.2.4 特权级转移 51   3.2.5 关于“保护”二字的一点思考 65   3.3 页式存储 65   3.3.1 分页机制概述 66   3.3.2 编写代码启动分页机制 67   3.3.3 PDE和PTE 68   3.3.4 cr3 71   3.3.5 回头看代码 72   3.3.6 克勤克俭用内存 73   3.3.7 进一步体会分页机制 81   3.4 中断和异常 87   3.4.1 中断和异常机制 87   3.4.2 外部中断 90   3.4.3 编程操作8259A 91   3.4.4 建立IDT 94   3.4.5 实现一个中断 95   3.4.6 时钟中断试验 96   3.4.7 几点额外说明 98   3.5 保护模式下的I/O 100   3.5.1 IOPL 100   3.5.2 I/O许可位图(I/O Permission Bitmap) 100   3.6 保护模式小结 101   第4章 让操作系统走进保护模式 102   4.1 突破512字节的限制 102   4.1.1 FAT12 103   4.1.2 DOS可以识别的引导盘 108   4.1.3 一个最简单的Loader 108   4.1.4 加载Loader入内存 109   4.1.5 向Loader交出控制权 116   4.1.6 整理boot.asm 116   4.2 保护模式下的“操作系统” 117   第5章 内核雏形 119   5.1 在Linux下用汇编写Hello World 119   5.2 再进一步,汇编和C同步使用 120   5.3 ELF(Executable and Linkable Format) 123   5.4 从Loader到内核 127   5.4.1 用Loader加载ELF 127   5.4.2 跳入保护模式 131   5.4.3 重新放置内核 137   5.4.4 向内核交出控制权 142   5.5 扩充内核 143   5.5.1 切换堆栈和GDT 144   5.5.2 整理我们的文件夹 148   5.5.3 Makefile 149   5.5.4 添加中断处理 155   5.5.5 两点说明 168   5.6 小结 169   第6章 进程 171   6.1 迟到的进程 171   6.2 概述 171   6.2.1 进程介绍 172   6.2.2 未雨绸缪——形成进程的必要考虑 172   6.2.3 参考的代码 173   6.3 最简单的进程 174   6.3.1 简单进程的关键技术预测 175   6.3.2 第一步——ring0→ring1 178   6.3.3 第二步——丰富中断处理程序 189   6.4 多进程 200   6.4.1 添加一个进程体 200   6.4.2 相关的变量和宏 200   6.4.3 进程表初始化代码扩充 202   6.4.4 LDT 203   6.4.5 修改中断处理程序 203   6.4.6 添加一个任务的步骤总结 206   6.4.7 号外:Minix的中断处理 207   6.4.8 代码回顾与整理 212   6.5 系统调用 220   6.5.1 实现一个简单的系统调用 222   6.5.2 get_ticks的应用 227   6.6 进程调度 232   6.6.1 避免对称——进程的节奏感 232   6.6.2 优先级调度总结 240   第7章 输入/输出系统 242   7.1 键盘 242   7.1.1 从中断开始——键盘初体验 242   7.1.2 AT、PS/2键盘 243   7.1.3 键盘敲击的过程 244   7.1.4 用数组表示扫描码 248   7.1.5 键盘输入缓冲区 251   7.1.6 用新加的任务处理键盘操作 253   7.1.7 解析扫描码 254   7.2 显示器 263   7.2.1 初识TTY 264   7.2.2 基本概念 264   7.2.3 寄存器 267   7.3 TTY任务 270   7.3.1 TTY任务框架的搭建 272   7.3.2 多控制台 277   7.3.3 完善键盘处理 281   7.3.4 TTY任务总结 288   7.4 区分任务和用户进程 289   7.5 printf 291   7.5.1 为进程指定TTY 292   7.5.2 printf()的实现 292   7.5.3 系统调用write() 294   7.5.4 使用printf() 296   下 篇   第8章 进程间通信 300   8.1 微内核还是宏内核 300   8.1.1 Linux的系统调用 302   8.1.2 Minix的系统调用 303   8.1.3 我们的选择 305   8.2 IPC 306   8.3 实现IPC 306   8.3.1 assert()和panic() 309   8.3.2 msg_send()和msg_receive() 313   8.3.3 增加消息机制之后的进程调度 321   8.4 使用IPC来替换系统调用get_ticks 322   8.5 总结 324   第9章 文件系统 325   9.1 硬盘简介 325   9.2 硬盘操作的I/O 端口 326   9.3 硬盘驱动程序 327   9.4 文件系统 337   9.5 硬盘分区表 338   9.6 设备号 344   9.7 用代码遍历所有分区 347   9.8 完善硬盘驱动程序 352   9.9 在硬盘上制作一个文件系统 355   9.9.1 文件系统涉及的数据结构 356   9.9.2 编码建立文件系统 358   9.10 创建文件 366   9.10.1 Linux下的文件操作 366   9.10.2 文件描述符(file descriptor) 367   9.10.3 open() 369   9.11 创建文件所涉及的其他函数 377   9.11.1 strip_path() 377   9.11.2 search_file() 378   9.11.3 get_inode()和sync_inode() 379   9.11.4 init_fs() 381   9.11.5 read_super_block()和get_super_block() 382   9.12 关闭文件 383   9.13 查看已创建的文件 384   9.14 打开文件 386   9.15 读写文件 387   9.16 测试文件读写 390   9.17 文件系统调试 393   9.18 删除文件 395   9.19 插曲:奇怪的异常 401   9.20 为文件系统添加系统调用的步骤 403   9.21 将TTY纳入文件系统 404   9.22 改造printf 411   9.23 总结 413   第10章 内存管理 414   10.1 fork 414   10.1.1 认识fork 414   10.1.2 fork前要做的工作(为fork所做的准备) 417   10.1.3 fork()库函数 421   10.1.4 MM 421   10.1.5 运行 427   10.2 exit和wait 427   10.3 exec 432   10.3.1 认识exec 433   10.3.2 为自己的操作系统编写应用程序 434   10.3.3 “安装”应用程序 436   10.3.4 实现exec 442   10.4 简单的shell 447   10.5 总结 449   第11章 尾声 451   11.1 让mkfs()只执行一次 451   11.2 从硬盘引导 455   11.2.1 编写硬盘引导扇区和硬盘版loader 455   11.2.2 “安装”hdboot.bin和hdldr.bin 461   11.2.3 grub 461   11.2.4 小结 463   11.3 将OS安装到真实的计算机 465   11.3.1 准备工作 465   11.3.2 安装Linux 466   11.3.3 编译源代码 466   11.3.4 开始安装 467   11.4 总结 467   参考文献 470 解密《一个操作系统的实现》这本书 5 月 18 日见到了《 Orange'S :一个操作系统的实现》的样书,多少有些激动。想一想前一版本《自己动手写操作系统》是那么畅销,这一本一定不能含糊。整个出版过程我能看到作者于渊为此付出的努力,还在自己排版的过程有深入体会,通过于渊的讲座也让博文视点的员工分享到他在排版过程中的很多心得。 应该有几万个朋友读过《自己动手写操作系统》了,本书的第 2 版《 Orange'S :一个操作系统的实现》出来肯定有非常多的朋友想问,这两本书到底有何区别呢?就此博文视点对本书作者于渊进行了简单的采访。 * 提问:《 Orange'S :一个操作系统的实现》与《自己动手写操作系统》明显区别在哪些方面? * 于渊:作为《自己动手写操作系统》(以下简称《自》)的第二版,《 Orange'S :一个操作系统的实现》(以下简称“新版”)主要有以下变化: 1. 书中示例操作系统的名字改为 Orange'S 2. 书名改为《 Orange'S :一个操作系统的实现》 3. 增加了有关 IPC 、 FS 、 MM 等内容 4. 将默认开发平台改为 GNU/Linux ,同时兼顾 Windows 5. 更改了排版工具,并使用技术手段增加书的可读性,比如代码行号的运用 6. 建立专门网站以服务读者 7. 建立专门讨论区供读者交流 读过《自己动手写操作系统》的读者一定知道,其中默认使用 Windows 作为开发平台,同时使用虚拟机来编译及运行自己的 OS ,在新版中这一点发生了变化(如上述第 4 条所述),具体的变化原因在书中第二章有详细的叙述。虽然开发平台是第二位的事情,但书中的默认平台却不免影响到叙述细节,所以,如果读者基于自己的原因坚持在 Windows 上开发(可能的原因或许有对 Linux 不熟悉、需要边开发操作系统边登录某些网上银行等等),则可能对读到的内容进行一点点额外加工。当然,所需的额外加工是少量的,而且在第二章中也有专门的文字介绍如何在两种平台下搭建工作环境。此外,如果读者不介意花钱,还可以同时购买《自己动手写操作系统》和新版,相互参照阅读。 * 提问:《 Orange'S :一个操作系统的实现》与《自己动手写操作系统》相比是否有所增加吗?增加了多少内容量呢? 于渊:新版的内容是有增加的,新增文字约占整本书的三分之一,《 Orange'S :一个操作系统的实现》新增代码则是《自己动手写操作系统》中代码的数倍。这些新增的内容,读者只能从新版中获得。目前并未有将新增内容单独成书的打算,所以读者即便仅想阅读第八章以后的内容,也需要购买整本《 Orange'S :一个操作系统的实现》。已经购买了《自己动手写操作系统》的读者可能觉得有点浪费,但事实并不如此,因为《自己动手写操作系统》的内容经过了重新排版、修订和编辑(比如代码格式进行了重排,更方便与光盘中的文件对照阅读,以及其中所有的矢量图都用 pgf/TikZ 重新绘制等)笔者倾注的心血使得新版的感官已经大为不同,读者一看便知。 * 提问:在《自己动手写操作系统》大卖的时候,您是否想过会有第二版出版呢? * 于渊:坦白讲,我在写作《自》的时候,并没有想过今天会有一个第二版。原因在于,我希望这本书是用来填补空白的,而不是重复去做别人已经做得很好的事情。所谓填补空白,具体说就是让像我一样的操作系统爱好者在读完本书之后,能够有信心去读其他比较流行的开源的操作系统代码,有能力从零开始自己动手写操作系统,而这个任务第一版已经完成了。 * 提问:那么为什么又写作了第二版呢? * 于渊:原因有几个方面。第一,虽然第一版未曾涉及的进程间通信、文件系统等内容在许多书中都有讲解,但阅读的时候还是感觉有语焉不详的通病,作者本人可能很清楚原委,但写得太简略,以至于读者看来未必清晰。第二,我自己想把这个圈画圆。第一版的书虽然完成了它的使命,但毕竟到书的结尾,读者看到的不是一个真正的操作系统,它没有文件系统,没有内存管理,什么也干不了。在第二版中,你将会看到,你已经可以通过交叉编译的方式为我们的实验性 OS 编写应用程序了,也就是说,它已经具备操作系统的基本功能,虽然仍然极其简陋,但第一个圈,毕竟是已经圆起来了。第三,实践类的操作系统书籍还是太少了,以至于你要想看看别人是怎么做的,除了读以《操作系统:设计与实现》为代表的极少数书籍之外,就是一头扎进源代码中,而结果有时相当令人气馁。我自己也气馁过,所以我在第二版中,仍然试图把话说细一点,把自己的经验拿出来分享。而且我选择我能想到的最精简的设计,以便让读者不至于陷入太多细节而无法看到全貌。我想这是本书可能具有的价值所在──简化的易懂的设计,还有尽量详细的文字。 * 提问:这本书为何不考虑用 WORD 排版? * 于渊:新版的排版是我用 LaTeX 自己完成的。在排版中我花了一些工夫,因为我希望读者购买的首先是一本易于阅读且赏心悦目的书,其次才是编写操作系统的方法。另外,书中列出的代码均由我自己编写的程序自动嵌入 LaTeX 源文件,从而严格保证书和光盘的一致性,读者可以根据文件名和行号方便地找到光盘中代码的准确位置。 * 提问:第二版还有哪些区别呢? Orange'S 这个名字很特别,有什么寓意吗? * 于渊:新版中还有一些小的变化。首先是操作系统的名字改变了,原因在于虽然我们的试验性 OS 从前辈们那里借鉴了很多东西,但其各个部分的设计(比如文件系统和内存管理)往往有其独特之处,所以我将原先的 Tinix (本意为 TryMinix )改成了新名字 Orange'S (这个名字来自于我的妻子),以表示它们的不同。另外,书中的代码风格,有些地方也做了调整。 新版中,原先的叙述风格都尽量地得以贯彻,而在表现形式上,新版用了更多心思,我相信读者能在其中发现这些特点:关注动手细节,探寻代码背后的故事,结果与过程兼顾,内容与形式并重。加上专门为本书建立的网站和讨论区,我相信读者能更容易地阅读,更轻松地学习。
内容简介   本书从只有二十行的引导扇区代码出发,一步一步地向读者呈现一个操作系统框架的完成过程。书中不仅关注代码本身,同时关注完成这些代码的思路和过程。本书不同于其他的理论型书籍,而是提供给读者一个动手实践的路线图。读者可以根据路线图逐步完成各部分的功能,从而避免了一开始就面对整个操作系统数万行代码时的迷茫和挫败感。书中讲解了大量在开发操作系统中需注意的细节问题,这些细节不仅能使读者更深刻地认识操作系统的核心原理,而且使整个开发过程少走弯路。本书分上下两篇,共11章。其中每一章都以前一章的工作成果为基础,实现一项新的功能。而在章的内部,一项大的功能被分解成许多小的步骤,通过完成每个小的步骤,读者可以不断获得阶段性的成果,从而让整个开发过程变得轻松并且有趣。   本书适合各类程序员、程序开发爱好者阅读,也可作为高等院校操作系统课程的实践参考书。 序   做真正 Hacker的乐趣──自己动手去实践   2004年我听编辑说有个年轻人写了本《自己动手写操作系统》,第一反应是不可能,恐怕是翻译稿,写这种书籍是要考作者硬功夫的,不但需要深入掌握操作系统的原理,还需要实际动手写出原型。   历史上的 Linux就是这么产生的,Linus Torvalds当时是一名赫尔辛基大学计算机科学系的二年级学生,经常要用自己的电脑去访问大学主机上的新闻组和邮件,为了方便读写和下载文件,他自己编写了磁盘驱动程序和文件系统,这成为了 Linux第一个内核的雏形。   我想中国有能力写出内核原型的程序员应该也有,但把这个题目写成一本书,感觉上不会有人愿意做这件事情,作者要花很多时间,加上主题比较硬,销售量不会太高,经济上回报有限。   但拿来文稿一看,整个编辑部大为惊艳,内容文笔俱佳,而且绝对原创,马上决定在《程序员》连载。2005年博文视点出版的第一版也广受好评。   不过有很多读者还是质疑:现在软件编程主要领域是框架和应用,还需要了解操作系统底层吗?   经过四年的磨练成长,于渊又拿出第二版的书稿《Orange'S:一个操作系统的实现》,这本书是属于真正 Hacker的。我虽然已经有多年不写代码了,但看这本书的时候,让我又重新感受到做程序员的乐趣:用代码建设属于自己的系统,让电脑听从自己的指令,对系统的每个部分都了如指掌。   黑客(hacker)实际是褒义词,维基百科的解释是喜欢用智力通过创造性方法来挑战脑力极限的人,特别是他们所感兴趣的领域,例如软件编程或电气工程。个人电脑、软件和互联网等划时代的产品都是黑客创造出来的,如苹果的 Apple电脑、微软的 Basic解释器、互联网的 Mosaic浏览器。   回答前面读者的质疑,学软件编程并不需要看这本书,想成为优秀程序员和黑客的朋友,我强烈建议你花时间来阅读这本书,并亲自动手实践。正如于渊在本书结尾中所说“我们写自己的操作系统是出于一种好奇,或者说一种求知欲。我希望这样不停地‘过把瘾’能让这种好奇不停地延续”。   好奇心是动力的源泉,追究问题的本质是优秀黑客的必备素质,只有充分掌握了系统原理,才能在技术上游刃有余,才能有真正的创新和发展。中国需要更多真正的黑客,也希望更多的程序员能享受属于黑客的创造乐趣。   蒋涛   2009年 4月 作者自序   本书是《自己动手写操作系统》的第二版,通过一个具体的实例向读者呈现一个操作系统雏形的实现过程。有关操作系统的书籍资料可以找到很多,但是关注如何帮助读者实现一个试验性操作系统的书籍却不多见,本书便是从一个简单的引导扇区开始,讲述一个操作系统成长的故事,以作读者参考之用。   本书面向实践,通过具体实例教读者开发自己的操作系统。书中的步骤遵循由小到大、由浅入深的顺序,跟随这些步骤,读者可以由一个最简单的引导扇区开始,逐渐完善代码,扩充功能,最后形成一个小的操作系统。   本书不仅介绍操作系统的各要素,同时涉及开发操作系统需要的各个方面,比如如何建立开发环境、如何调试以及如何在虚拟机中运行等。书中的实例操作系统采用IA32作为默认平台,所以保护模式也作为必备知识储备收入书中,而这是传统的操作系统实践书籍经常忽略的。总之,只要是开发自己的操作系统中需要的知识,书中都尽量涉及,以便于读者参考。   众所周知,一个成型的操作系统往往非常复杂。如果考虑到操作系统作为软硬件桥梁的特殊地位,那么它可能看上去比一般的软件系统更难理解,因为其核心部分往往包含许多直接针对CPU、内存和 I/O端口的操作,它们夹杂在一片代码汪洋之中,显得更加晦涩。   我们有许多源代码公开的操作系统,可供随时下载和阅读,看上去好像让实现一个供自己把玩的微型操作系统变得容易很多,但事实往往不尽人意,因为这些代码动辄上万甚至几十几百万行,而且细节之间经常互相关联,要理解它们着实不易。我们有许多容易得到的操作系统教程,但读来好像总觉得跟我们有隔膜,不亲近。造成这些的根本原因,在于学习者一开始就面对一个完整的操作系统,或者面对前辈们积累了几十年的一系列理论成果。而无论作者多么擅长写作,读者多么聪明,或者代码多么优秀,要一个初学者理清其中的头绪都将是非常困难的。   我并非在此危言耸听,因为这曾经是我的亲身体会。当然,如果只是为了考试,几本操作系统理论书籍就足够了,你不需要对细节那么清楚。但如果是出于兴趣呢?如果你是想编写自己的操作系统呢?你会发现理论书籍好像一下子变得无用武之地,你会发现任何一个细节上的理解错误都可能导致自己辛辛苦苦编写的代码运行异常甚至崩溃。   我经历过这一切!我曾经翻遍了一本《操作系统:设计与实现》,也没有找到实现一个操作系统应该从何处着手。并不是这些书不好,也不是前人的代码不优秀,而是作为一无所知的初学者,我们所不了解的不仅是高居庙堂的理论知识,还有让我们举步维艰的实践细节。   可能在这些教科书作者的眼里,操作的细节不属于课程的一部分,或者这些细节看上去太容易,根本不值一提,甚至作者认为这些属于所谓“经验”的一部分,约定俗成是由读者本人去摸索的。但是实际情况往往是,这些书中忽略掉的内容恰恰占去了一个初学者大部分的时间,甚至影响了学习的热情。   我至今仍记得当我开始编写自己的操作系统时所遭受的挫败感,那是一种不知道如何着手的无助的感觉。还好我坚持了下来,克服了各种困难,并完成了自己的操作系统雏形。   进而我想到,一定不只是我一个人对编写自己的操作系统怀有兴趣,也一定不只是我一个人在实践时遇到困难。或许我应该把自己的经历写下来,从而可以帮助跟我相似的后来者,就这样,我编写了本书的第一版,也就是《自己动手写操作系统》。我相信,如果你也对神奇的计算机世界充满好奇,并且希望通过自己编写操作系统的方式来了解背后发生的故事,那么你一定可以在这本书中得到一些帮助。而假如你真的因为我的书而重新燃起实践的热情,从而开始一段操作系统旅程,我将会感到非常高兴。   不过我得坦白,在写作《自己动手写操作系统》的时候,我并不敢期待它能引起多少反响,一方面因为操作系统并不是时尚的话题,另一方面我也是走在学习的路上,或许只是比读者早走了一小步而已。然而出乎我的意料,它面世后重印多次,甚至一度登上销量排行榜的榜首,这让我觉得它的确有一定的参考价值,我要借此机会感谢所有支持我的读者。   在我写作《自己动手写操作系统》的时候,并没有想过今天会有一个第二版。原因在于,我希望这本书是用来填补空白的,而不是重复去做别人已经做得很好的事情。所谓填补空白,具体说就是让像我一样的操作系统爱好者在读完本书之后,能够有信心去读其他比较流行的开源的操作系统代码,有能力从零开始自己动手写操作系统,而这个任务第一版已经完成了。   那么为什么我又写作了第二版呢?原因有几个方面。第一,虽然第一版未曾涉及的进程间通信、文件系统等内容在许多书中都有讲解,但阅读的时候还是感觉有语焉不详的通病,作者本人可能很清楚原委,但写得太简略,以至于读者看来未必清晰。第二,我自己想把这个圈画圆。第一版的书虽然完成了它的使命,但毕竟到书的结尾,读者看到的不是一个真正的操作系统,它没有文件系统,没有内存管理,什么也干不了。在第二版中,你将会看到,你已经可以通过交叉编译的方式为我们的实验性 OS编写应用程序了,也就是说,它已经具备操作系统的基本功能,虽然仍然极其简陋,但第一个圈,毕竟是已经圆起来了。第三,实践类的操作系统书籍还是太少了,以至于你要想看看别人是怎么做的,除了读以《操作系统:设计与实现》为代表的极少数书籍之外,就是一头扎进源代码中,而结果有时相当令人气馁。我自己也气馁过,所以我在第二版中,仍然试图把话说细一点,把自己的经验拿出来分享。而且我选择我能想到的最精简的设计,以便让读者不至于陷入太多细节而无法看到全貌。我想这是本书可能具有的价值所在──简化的易懂的设计,还有尽量详细的文字。   在这一版中,内容被划分成上下两篇。上篇基本上是第一版的修订,只是做了一个调整,那便是在兼顾 Windows和Linux两方面用户的基础上,默认在Linux下建立开发环境来编写我们的操作系统。至于这样做的原因,在本书第 2章有比较详细的说明。当然,开发环境毕竟是第二位的,书中讲述的内容以及涉及的代码跟第一版都是一致的。本书的下篇全部都是新鲜内容,主要是增加了进程间通信、文件系统和内存管理。跟第一版的做法相同,下篇仍然不仅关注结果,更加致力于将形成一个结果的过程呈现出来。与此同时,由于本书旨在分享和引路,所以尽可能地简化了设计,以便将最重要的部分凸显出来。读者将看到,一个操作系统的文件系统和内存管理可以简陋到什么程度。简陋不是缺点,对于我们初学者而言,正是需要从简陋入手。换言之,如果你已经对实现一个操作系统有了一定的经验,那么这本书可能不适合你。这本书适合从来没有编写过操作系统的初学者。   本书的排版是我用L ATEX自己完成的。在排版中我花了一些工夫,因为我希望读者购买的首先是一本易于阅读且赏心悦目的书,其次才是编写操作系统的方法。另外,书中列出的代码均由我自己编写的程序自动嵌入L ATEX源文件,从而严格保证书和光盘的一致性,读者可以根据文件名和行号方便地找到光盘中   代码的准确位置。   此外,在第二版中还有一些小的变化。首先是操作系统的名字改变了,原因在于虽然我们的试验性   OS从前辈们那里借鉴了很多东西,但其各个部分的设计(比如文件系统和内存管理)往往有其独特之处,所以我将原先的 Tinix(本意为 TryMinix)改成了新名字Orange ’S(这个名字来自于我的妻子 ,),以表示它们的不同。另外,书中的代码风格,有些地方也做了调整。   我想,虽然第二版有着这样那样的变化,但有一点没有变,那就是本书试图将我在编写自己操作系统的过程中的经验尽可能地告诉读者,同时尽可能将我当初的思路和编码过程呈现出来。很可能读者比我更聪明,有更好的解决问题的方法,但无论如何,我认为我自己的经验可以为读者所借鉴。如果真是如   此,我将会非常欣慰。   在第二版的编写过程中,我同样要感谢许多人。感谢我的父母和爷爷对我的爱,并希望爷爷不要为我担心,写书是件辛苦的事,但同时也使我收获良多。爸爸在第二版的最后阶段帮我订正文字,这本书里有你的功劳。我要感谢博文视点的各位朋友,感谢郭老师的理解和支持,感谢李玲的辛勤工作,感谢江立和李冰,你们的高效让我非常钦佩。我还要感谢孟岩老师,你给我的鼓励我一直记在心里。我要感谢我的挚友郭洪桥,不仅仅因为你在技术上给我的帮助,更加因为你在精神上给我的支持。感谢我的同事和朋友张会昌,你在技术上的广度和深度总令我钦佩。另外,在第一版中帮助我的人,我要再次谢谢你们,因为没有第一版,也就没有第二版。   在所有人中我最应该感谢和最想感谢的,是我的妻子黄丹红,感谢你给我的所有建议,还有你帮我画的图。尤其是,当这本书在我预想的时间内没有完成的时候,当我遇到困难迟迟不能解决的时候,你总在一旁给我鼓励,在你那里,我从来都能感觉到一种温暖,我深知,如果没有你的支持,我无法坚持下来将书写完。谢谢你,这本书同样属于你。   跟第一版相比,这本书涉及的内容触及操作系统设计的更多方面,而由于笔者的水平实在有限,难免有纰漏甚至错误。如果读者有任何的问题、意见或建议,请登录http://www.osfromscratch.org,让我们共同探讨,共同进步。   本书导读   这本书适合谁   本书是一本操作系统实践的技术书籍。对于操作系统技术感兴趣,想要亲身体验编写操作系统过程的实践主义者,以及Minix、Linux源代码爱好者,都可以在本书中得到实践中所需的知识和思路。   本书以“动手写”为指导思想,只要是跟“动手写”操作系统有关的知识,都作为介绍对象加以讨论,所以,从开发环境的搭建,到保护模式,再到IBMPC中有关芯片的知识,最后到操作系统本身的设计实现,都能在本文中找到相应介绍。所以如果你也想亲身实践的话,本书可以省去你在书店和互联网寻找相应资料的过程,使你的学习过程事半功倍。在读完本书后,你不但可以获得对于操作系统初步的感性认识,并且对 IBMPC的接口、IA架构之保护模式,以及操作系统整体上的框架都将会有一定程度的了解。   笔者相信,当你读完本书之后,如果再读那些纯理论性的操作系统书籍,所获得的体验将会完全不同,因为那些对你而言不再是海市蜃楼。   对于想阅读 Linux源代码的操作系统爱好者,本书可以提供阅读前所必要的知识储备,而这些知识储备不但在本书中有完整的涉及,而且在很多 Linux书籍中是没有提到的。   特别要提到的是,对于想通过阅读 Andrew S. Tanenbaum和 Albert S. Woodhull的《操作系统:设计与实现》来学习操作系统的读者,本书尤其适合作为你的引路书籍,因为它翔实地介绍了初学者入门时所必需的知识积累,而这些知识在《操作系统:设计与实现》一书中是没有涉及的,笔者本人是把这本书作为写操作系统的主要参考书籍之一,所以在本书中对它多有借鉴。   你需要什么技术基础   在本书中所用到的计算机语言只有两种:汇编和 C语言。所以只要你具备汇编和 C语言的经验,就可以阅读本书。除对操作系统常识性的了解(比如知道中断、进程等概念)之外,本书不假定读者具备其他任何经验。   如果你学习过操作系统的理论课程,你会发现本书是对于理论的吻合和补充。它是从实践的角度为你展现一幅操作系统画面。   书中涉及了 Intel CPU保护模式、Linux命令等内容,到时候会有尽可能清晰的讲解,如果笔者认为某些内容可以通过其他教材系统学习,会在书中加以说明。   另外,本书只涉及 Intel x86平台。   统一思想——让我们在这些方面达成共识   道篇   让我们有效而愉快地学习   你大概依然记得在你亲自敲出第一个“Hello world”程序并运行成功时的喜悦,那样的成就感助燃了你对编写程序浓厚的兴趣。随后你不断地学习,每学到新的语法都迫不及待地在计算机上调试运行,在调试的过程中克服困难,学到新知,并获得新的成就感。   可现在请你设想一下,假如课程不是这样的安排,而是先试图告诉你所有的语法,中间没有任何实践的机会,试问这样的课程你能接受吗?我猜你唯一的感受将是索然寡味。   原因何在?只是因为你不再有因为不断实践而获得的源源不断的成就感。而成就感是学习过程中快乐的源泉,没有了成就感,学习的愉快程度将大打折扣,效果于是也将变得不容乐观。   每个人都希望有效而且愉快的学习过程,可不幸的是,我们见到的操作系统课程十之八九令我们失望,作者喋喋不休地讲述着进程管理存储管理I/O控制调度算法,可我们到头来也没有一点的感性认识。我们好像已经理解却又好像一无所知。很明显,没有成就感,一点也没有。笔者痛恨这样的学习过程,也决不会重蹈这样的覆辙,让读者获得成就感将是本书的灵魂。   其实这本书完全可以称作一本回忆录,记载了笔者从开始不知道保护模式为何物到最终形成一个小小   OS的过程,这样的回忆录性质保证了章节的安排完全遵从操作的时间顺序,于是也就保证了每一步的可操作性,毫无疑问,顺着这样的思路走下来,每一章的成果都需要努力但又尽在眼前,步步为营是我   们的战术,成就感是我们的宗旨。   我们将从二十行代码开始,让我们最简单的操作系统婴儿慢慢长大,变成一个翩翩少年,而其中的每一步,你都可以在书中的指导下自己完成,不仅仅是看到,而是自己做到!你将在不断的实践中获得不断的成就感,笔者真心希望在阅读本书的过程中,你的学习过程可以变得愉快而有效。   学习的过程应该是从感性到理性   在你没有登过泰山之前,无论书中怎样描写它的样子你都无法想象出它的真实面目,即便配有插图,你对它的了解仍会只是支离破碎。毫无疑问,一千本对泰山描述的书都比不上你一次登山的经历。文学家的描述可能是华丽而优美的,可这样的描述最终产生的效果可能是你非去亲自登泰山不可。反过来想呢,假如你已经登过泰山,这样的经历产生的效果会是你想读尽天下描述泰山的书而后快吗?可能事实恰恰相反,你可能再也不想去看那些文字描述。   是啊,再好的讲述,又哪比得上亲身的体验?人们的认知规律本来如此,有了感性的认识,才能上升为理性的理论。反其道而行之只能是事倍功半。   如果操作系统是一座这样的大山,本书愿做你的导游,引领你进入它的门径。传统的操作系统书籍仅仅是给你讲述这座大山的故事,你只是在听讲,并没有身临其境,而随着这本书亲身体验,则好像置身于山门之内,你不但可以看见眼前的每一个细节,更是具有了走完整座大山的信心。   值得说明的是,本书旨在引路,不会带领你走完整座大山,但是有兴趣的读者完全可以在本书最终形成的框架的基础上容易地实现其他操作系统书籍中讲到的各种原理和算法,从而对操作系统有个从感性到理性的清醒认识。   暂时的错误并不可怕   当我们对一件事情的全貌没有很好理解的时候,很可能会对某一部分产生理解上的误差,这就是所谓的断章取义。很多时候断章取义是难免的,但是,在不断学习的过程中,我们会逐渐看到更多,了解更多,对原先事物的认识也会变得深刻甚至不同。   对于操作系统这样复杂的东西来说,要想了解所有的细节无疑是非常困难的,所以在实践的过程中,可能在很多地方,会有一些误解发生。这都没有关系,随着了解的深入,这些误解总会得到澄清,到时你会发现,自己对某一方面已经非常熟悉了,这时的成就感,一定会让你感到非常愉悦。   本书内容的安排遵从的是代码编写的时间顺序,它更像是一本开发日记,所以在书中一些中间过程不完美的产物被有意保留了下来,并会在以后的章节中对它们进行修改和完善,因为笔者认为,一些精妙的东西背后,一定隐藏着很多中间的产物,一个伟大的发现在很多情况下可能不是天才们刹那间的灵光一闪,背后也一定有着我们没有看到的不伟大甚至是谬误。笔者很想追寻前辈们的脚步,重寻他们当日的足迹。做到这一点无疑很难,但即便无法做到,只要能引起读者的一点思索,也是本书莫大的幸事。   挡住了去路的,往往不是大树,而是小藤   如果不是亲身去做,你可能永远都不知道,困难是什么。   就好像你买了一台功能超全的微波炉回家,研究完了整本说明书,踌躇满志想要烹饪的时候,却突然发现家里的油盐已经用完。而当时已经是晚上十一点,所有的商店都已经关门,你气急败坏,简直想摸起铁勺砸向无辜的微波炉。   研究说明书是没有错的,但是在没开始之前,你永远都想不到让你无法烹饪的原因居然是十块钱一瓶的油和一块钱一袋的更加微不足道的盐。你还以为困难是微波炉面板上密密麻麻的控制键盘。   其实做其他事情也是一样的,比如写一个操作系统,即便一个很小的可能受理论家们讥笑的操作系统雏形,仍然可能遇到一大堆你没有想过的问题,而这些问题在传统的操作系统书籍中根本没有提到。所以唯一的办法,便是亲自去做,只有实践了,才知道是怎么回事。   术篇   用到什么再学什么   我们不是在考试,我们只是在为了自己的志趣而努力,所以就让我们忠于自己的喜好吧,不必为了考试而看完所有的章节,无论那是多么的乏味。让我们马上投入实践,遇到问题再图解决的办法。笔者非常推崇这样的学习方法:   实践 →遇到问题 →解决问题 →再实践   因为我们知道我们为什么学习,所以我们才会非常投入;由于我们知道我们的目标是解决什么问题,所以我们才会非常专注;由于我们在实践中学习,所以我们才会非常高效。而最有趣的是,最终你会发现你并没有因为选择这样的学习方法而少学到什么,相反,你会发现你用更少的时间学到更多的东西,并且格外的扎实。   只要用心,就没有学不会的东西   笔者还清楚地记得刚刚下载完 Intel Architecture Software Developer Manual那三个可怕的 PDF文件时的心情,那时心里暗暗嘀咕,什么时候才能把这些东西读懂啊!可是突然有一天,当这些东西真的已经被基本读完的时候,我想起当初的畏惧,时间其实并没有过去多少。   所有的道理都是相通的,没有什么真正可怕,尤其是,我们所做的并非创造性的工作,所有的问题前人都曾经解决,所以我们更是无所畏惧,更何况我们不仅有书店,而且有互联网,动动手脚就能找到需要的资料,我们只要认真研究就够了。   所以当遇到困难时,请静下心来,慢慢研究,因为只要用心,就没有学不会的东西。   适当地囫囵吞枣   如果囫囵吞枣仅仅是学习的一个过程而非终点,那么它并不一定就是坏事。大家都应该听说过鲁迅先生学习英语的故事,他建议在阅读的过程中遇到不懂的内容可以忽略,等到过一段时间之后,这些问题会自然解决。   在本书中,有时候可能先列出一段代码,告诉你它能完成什么,这时你也可以大致读过,因为下面会有对它详细的解释。第一遍读它的时候,你只要了解大概就够了。    本书的原则   1.宁可啰嗦一点,也不肯漏掉细节   在书中的有些地方,你可能觉得有些很“简单”的问题都被列了出来,甚至显得有些啰嗦,但笔者宁可让内容写得啰嗦点,因为笔者自己在读书的时候有一个体验,就是有时候一个问题怎么也想不通,经过很长时间终于弄明白的时候才发现原来是那么“简单”。可能作者认为它足够简单以至于可以跳过不提,但读者未必那么幸运一下子就弄清楚。   不过本书到后面的章节,如果涉及的细节是前面章节提到过的,就有意地略过了。举个非常简单的例子,开始时本书会提醒读者增加一个源文件之后不要忘记修改Makefile,到后来就假定读者已经熟悉了这个步骤,可能就不再提及了。   2.努力做到平易近人   笔者更喜欢把本书称作一本笔记或者学习日志,不仅仅是因为它基本是真实的学习过程的再现,而且笔者不想让它有任何居高临下甚至是晦涩神秘的感觉。如果有一个地方你觉得书中没有说清楚以至于你没有弄明白,请你告诉我,我会在以后做出改进。 3.代码注重可读性但不注重效率   本书的代码力求简单易懂,在此过程中很少考虑运行的效率。一方面因为书中的代码仅仅供学习之用,暂时并不考虑实际用途;另一方面笔者认为当我们对操作系统足够了解之后再考虑效率的问题也不迟。   本书附带光盘说明   本书附带光盘中有本书用到的所有源代码。值得一提的是,其中不止包含完整的操作系统代码,还包含各个步骤的中间产物。换句话说,开发中每一步骤的代码,都可在光盘中单独文件夹中找到。举例说明,书的开篇介绍引导扇区,读者在相应文件夹中就只看到引导扇区的代码;第 9章介绍文件系统,在相应文件夹中就不会包含第 10章内存管理的代码。在任何一个步骤对应的文件夹中,都包含一个完整可编译运行的代码树,以方便读者试验之用。这样在学习的任何一个阶段,读者都可彻底了解阶段性成果,且不必担心受到自己还未学习的内容的影响,从而使学习不留死角。   在书的正文中引用的代码会标注出出自哪个文件。以“chapter5/b/bar.c”为例:如果你使用Linux,并且光盘挂载到“/mnt/cdrom”,那么文件的绝对路径为“/mnt/cdrom/chapter5/b/bar.c”;如果你使用Windows,并且光盘是 X:盘,那么文件的绝对路径为“X:nchapter5nbnbar.c”。 目 录   上 篇   第1章 马上动手写一个最小的“操作系统” 2   1.1 准备工作 2   1.2 十分钟完成的操作系统 3   1.3 引导扇区 4   1.4 代码解释 4   1.5 水面下的冰山 6   1.6 回顾 7   第2章 搭建你的工作环境 8   2.1 虚拟计算机Bochs 8   2.1.1 Bochs初体验 8   2.1.2 Bochs的安装 9   2.1.3 Bochs的使用 10   2.1.4 用Bochs调试操作系统 12   2.2 QEMU 15   2.3 平台之争:Windows还是*nix 16   2.4 GNU/Linux下的开发环境 20   2.5 Windows下的开发环境 22   2.6 总结 23   第3章 保护模式(Protect Mode) 25   3.1 认识保护模式 25   3.1.1 保护模式的运行环境 29   3.1.2 GDT(Global Descriptor Table) 31   3.1.3 实模式到保护模式,不一般的jmp 33   3.1.4 描述符属性 35   3.2 保护模式进阶 38   3.2.1 海阔凭鱼跃 38   3.2.2 LDT(Local Descriptor Table) 44   3.2.3 特权级概述 48   3.2.4 特权级转移 51   3.2.5 关于“保护”二字的一点思考 65   3.3 页式存储 65   3.3.1 分页机制概述 66   3.3.2 编写代码启动分页机制 67   3.3.3 PDE和PTE 68   3.3.4 cr3 71   3.3.5 回头看代码 72   3.3.6 克勤克俭用内存 73   3.3.7 进一步体会分页机制 81   3.4 中断和异常 87   3.4.1 中断和异常机制 87   3.4.2 外部中断 90   3.4.3 编程操作8259A 91   3.4.4 建立IDT 94   3.4.5 实现一个中断 95   3.4.6 时钟中断试验 96   3.4.7 几点额外说明 98   3.5 保护模式下的I/O 100   3.5.1 IOPL 100   3.5.2 I/O许可位图(I/O Permission Bitmap) 100   3.6 保护模式小结 101   第4章 让操作系统走进保护模式 102   4.1 突破512字节的限制 102   4.1.1 FAT12 103   4.1.2 DOS可以识别的引导盘 108   4.1.3 一个最简单的Loader 108   4.1.4 加载Loader入内存 109   4.1.5 向Loader交出控制权 116   4.1.6 整理boot.asm 116   4.2 保护模式下的“操作系统” 117   第5章 内核雏形 119   5.1 在Linux下用汇编写Hello World 119   5.2 再进一步,汇编和C同步使用 120   5.3 ELF(Executable and Linkable Format) 123   5.4 从Loader到内核 127   5.4.1 用Loader加载ELF 127   5.4.2 跳入保护模式 131   5.4.3 重新放置内核 137   5.4.4 向内核交出控制权 142   5.5 扩充内核 143   5.5.1 切换堆栈和GDT 144   5.5.2 整理我们的文件夹 148   5.5.3 Makefile 149   5.5.4 添加中断处理 155   5.5.5 两点说明 168   5.6 小结 169   第6章 进程 171   6.1 迟到的进程 171   6.2 概述 171   6.2.1 进程介绍 172   6.2.2 未雨绸缪——形成进程的必要考虑 172   6.2.3 参考的代码 173   6.3 最简单的进程 174   6.3.1 简单进程的关键技术预测 175   6.3.2 第一步——ring0→ring1 178   6.3.3 第二步——丰富中断处理程序 189   6.4 多进程 200   6.4.1 添加一个进程体 200   6.4.2 相关的变量和宏 200   6.4.3 进程表初始化代码扩充 202   6.4.4 LDT 203   6.4.5 修改中断处理程序 203   6.4.6 添加一个任务的步骤总结 206   6.4.7 号外:Minix的中断处理 207   6.4.8 代码回顾与整理 212   6.5 系统调用 220   6.5.1 实现一个简单的系统调用 222   6.5.2 get_ticks的应用 227   6.6 进程调度 232   6.6.1 避免对称——进程的节奏感 232   6.6.2 优先级调度总结 240   第7章 输入/输出系统 242   7.1 键盘 242   7.1.1 从中断开始——键盘初体验 242   7.1.2 AT、PS/2键盘 243   7.1.3 键盘敲击的过程 244   7.1.4 用数组表示扫描码 248   7.1.5 键盘输入缓冲区 251   7.1.6 用新加的任务处理键盘操作 253   7.1.7 解析扫描码 254   7.2 显示器 263   7.2.1 初识TTY 264   7.2.2 基本概念 264   7.2.3 寄存器 267   7.3 TTY任务 270   7.3.1 TTY任务框架的搭建 272   7.3.2 多控制台 277   7.3.3 完善键盘处理 281   7.3.4 TTY任务总结 288   7.4 区分任务和用户进程 289   7.5 printf 291   7.5.1 为进程指定TTY 292   7.5.2 printf()的实现 292   7.5.3 系统调用write() 294   7.5.4 使用printf() 296   下 篇   第8章 进程间通信 300   8.1 微内核还是宏内核 300   8.1.1 Linux的系统调用 302   8.1.2 Minix的系统调用 303   8.1.3 我们的选择 305   8.2 IPC 306   8.3 实现IPC 306   8.3.1 assert()和panic() 309   8.3.2 msg_send()和msg_receive() 313   8.3.3 增加消息机制之后的进程调度 321   8.4 使用IPC来替换系统调用get_ticks 322   8.5 总结 324   第9章 文件系统 325   9.1 硬盘简介 325   9.2 硬盘操作的I/O 端口 326   9.3 硬盘驱动程序 327   9.4 文件系统 337   9.5 硬盘分区表 338   9.6 设备号 344   9.7 用代码遍历所有分区 347   9.8 完善硬盘驱动程序 352   9.9 在硬盘上制作一个文件系统 355   9.9.1 文件系统涉及的数据结构 356   9.9.2 编码建立文件系统 358   9.10 创建文件 366   9.10.1 Linux下的文件操作 366   9.10.2 文件描述符(file descriptor) 367   9.10.3 open() 369   9.11 创建文件所涉及的其他函数 377   9.11.1 strip_path() 377   9.11.2 search_file() 378   9.11.3 get_inode()和sync_inode() 379   9.11.4 init_fs() 381   9.11.5 read_super_block()和get_super_block() 382   9.12 关闭文件 383   9.13 查看已创建的文件 384   9.14 打开文件 386   9.15 读写文件 387   9.16 测试文件读写 390   9.17 文件系统调试 393   9.18 删除文件 395   9.19 插曲:奇怪的异常 401   9.20 为文件系统添加系统调用的步骤 403   9.21 将TTY纳入文件系统 404   9.22 改造printf 411   9.23 总结 413   第10章 内存管理 414   10.1 fork 414   10.1.1 认识fork 414   10.1.2 fork前要做的工作(为fork所做的准备) 417   10.1.3 fork()库函数 421   10.1.4 MM 421   10.1.5 运行 427   10.2 exit和wait 427   10.3 exec 432   10.3.1 认识exec 433   10.3.2 为自己的操作系统编写应用程序 434   10.3.3 “安装”应用程序 436   10.3.4 实现exec 442   10.4 简单的shell 447   10.5 总结 449   第11章 尾声 451   11.1 让mkfs()只执行一次 451   11.2 从硬盘引导 455   11.2.1 编写硬盘引导扇区和硬盘版loader 455   11.2.2 “安装”hdboot.bin和hdldr.bin 461   11.2.3 grub 461   11.2.4 小结 463   11.3 将OS安装到真实的计算机 465   11.3.1 准备工作 465   11.3.2 安装Linux 466   11.3.3 编译源代码 466   11.3.4 开始安装 467   11.4 总结 467   参考文献 470 解密《一个操作系统的实现》这本书 5 月 18 日见到了《 Orange'S :一个操作系统的实现》的样书,多少有些激动。想一想前一版本《自己动手写操作系统》是那么畅销,这一本一定不能含糊。整个出版过程我能看到作者于渊为此付出的努力,还在自己排版的过程有深入体会,通过于渊的讲座也让博文视点的员工分享到他在排版过程中的很多心得。 应该有几万个朋友读过《自己动手写操作系统》了,本书的第 2 版《 Orange'S :一个操作系统的实现》出来肯定有非常多的朋友想问,这两本书到底有何区别呢?就此博文视点对本书作者于渊进行了简单的采访。 * 提问:《 Orange'S :一个操作系统的实现》与《自己动手写操作系统》明显区别在哪些方面? * 于渊:作为《自己动手写操作系统》(以下简称《自》)的第二版,《 Orange'S :一个操作系统的实现》(以下简称“新版”)主要有以下变化: 1. 书中示例操作系统的名字改为 Orange'S 2. 书名改为《 Orange'S :一个操作系统的实现》 3. 增加了有关 IPC 、 FS 、 MM 等内容 4. 将默认开发平台改为 GNU/Linux ,同时兼顾 Windows 5. 更改了排版工具,并使用技术手段增加书的可读性,比如代码行号的运用 6. 建立专门网站以服务读者 7. 建立专门讨论区供读者交流 读过《自己动手写操作系统》的读者一定知道,其中默认使用 Windows 作为开发平台,同时使用虚拟机来编译及运行自己的 OS ,在新版中这一点发生了变化(如上述第 4 条所述),具体的变化原因在书中第二章有详细的叙述。虽然开发平台是第二位的事情,但书中的默认平台却不免影响到叙述细节,所以,如果读者基于自己的原因坚持在 Windows 上开发(可能的原因或许有对 Linux 不熟悉、需要边开发操作系统边登录某些网上银行等等),则可能对读到的内容进行一点点额外加工。当然,所需的额外加工是少量的,而且在第二章中也有专门的文字介绍如何在两种平台下搭建工作环境。此外,如果读者不介意花钱,还可以同时购买《自己动手写操作系统》和新版,相互参照阅读。 * 提问:《 Orange'S :一个操作系统的实现》与《自己动手写操作系统》相比是否有所增加吗?增加了多少内容量呢? 于渊:新版的内容是有增加的,新增文字约占整本书的三分之一,《 Orange'S :一个操作系统的实现》新增代码则是《自己动手写操作系统》中代码的数倍。这些新增的内容,读者只能从新版中获得。目前并未有将新增内容单独成书的打算,所以读者即便仅想阅读第八章以后的内容,也需要购买整本《 Orange'S :一个操作系统的实现》。已经购买了《自己动手写操作系统》的读者可能觉得有点浪费,但事实并不如此,因为《自己动手写操作系统》的内容经过了重新排版、修订和编辑(比如代码格式进行了重排,更方便与光盘中的文件对照阅读,以及其中所有的矢量图都用 pgf/TikZ 重新绘制等)笔者倾注的心血使得新版的感官已经大为不同,读者一看便知。 * 提问:在《自己动手写操作系统》大卖的时候,您是否想过会有第二版出版呢? * 于渊:坦白讲,我在写作《自》的时候,并没有想过今天会有一个第二版。原因在于,我希望这本书是用来填补空白的,而不是重复去做别人已经做得很好的事情。所谓填补空白,具体说就是让像我一样的操作系统爱好者在读完本书之后,能够有信心去读其他比较流行的开源的操作系统代码,有能力从零开始自己动手写操作系统,而这个任务第一版已经完成了。 * 提问:那么为什么又写作了第二版呢? * 于渊:原因有几个方面。第一,虽然第一版未曾涉及的进程间通信、文件系统等内容在许多书中都有讲解,但阅读的时候还是感觉有语焉不详的通病,作者本人可能很清楚原委,但写得太简略,以至于读者看来未必清晰。第二,我自己想把这个圈画圆。第一版的书虽然完成了它的使命,但毕竟到书的结尾,读者看到的不是一个真正的操作系统,它没有文件系统,没有内存管理,什么也干不了。在第二版中,你将会看到,你已经可以通过交叉编译的方式为我们的实验性 OS 编写应用程序了,也就是说,它已经具备操作系统的基本功能,虽然仍然极其简陋,但第一个圈,毕竟是已经圆起来了。第三,实践类的操作系统书籍还是太少了,以至于你要想看看别人是怎么做的,除了读以《操作系统:设计与实现》为代表的极少数书籍之外,就是一头扎进源代码中,而结果有时相当令人气馁。我自己也气馁过,所以我在第二版中,仍然试图把话说细一点,把自己的经验拿出来分享。而且我选择我能想到的最精简的设计,以便让读者不至于陷入太多细节而无法看到全貌。我想这是本书可能具有的价值所在──简化的易懂的设计,还有尽量详细的文字。 * 提问:这本书为何不考虑用 WORD 排版? * 于渊:新版的排版是我用 LaTeX 自己完成的。在排版中我花了一些工夫,因为我希望读者购买的首先是一本易于阅读且赏心悦目的书,其次才是编写操作系统的方法。另外,书中列出的代码均由我自己编写的程序自动嵌入 LaTeX 源文件,从而严格保证书和光盘的一致性,读者可以根据文件名和行号方便地找到光盘中代码的准确位置。 * 提问:第二版还有哪些区别呢? Orange'S 这个名字很特别,有什么寓意吗? * 于渊:新版中还有一些小的变化。首先是操作系统的名字改变了,原因在于虽然我们的试验性 OS 从前辈们那里借鉴了很多东西,但其各个部分的设计(比如文件系统和内存管理)往往有其独特之处,所以我将原先的 Tinix (本意为 TryMinix )改成了新名字 Orange'S (这个名字来自于我的妻子),以表示它们的不同。另外,书中的代码风格,有些地方也做了调整。 新版中,原先的叙述风格都尽量地得以贯彻,而在表现形式上,新版用了更多心思,我相信读者能在其中发现这些特点:关注动手细节,探寻代码背后的故事,结果与过程兼顾,内容与形式并重。加上专门为本书建立的网站和讨论区,我相信读者能更容易地阅读,更轻松地学习。
内容简介 《LINUX设备驱动程序(第3版)》已针对Linux内核的2610版本彻底更新过了。内核的这个版本针对常见任务完成了合理化设计及相应的简化,如即插即用、利用sysfs文件系统和用户空间交互,以及标准总线上的多设备管理等等。要阅读并理解本书,您不必首先成为内核黑客;只要您理解C语言并具有Unix系统调用的一些背景知识即可。您将学到如何为字符设备、块设备和网络接口编写驱动程序。为此,《LINUX设备驱动程序(第3版)》提供了完整的示例程序,您不需要特殊的硬件即可编译和运行这些示例程序。《LINUX设备驱动程序(第3版)》还在单独的章节中讲述了PCI、USB和tty(终端)子系统。对期望了解操作系统内部工作原理的读者来讲,《LINUX设备驱动程序(第3版)》也深入阐述了地址空间、异步事件以及I/O等方面的内容。 作者简介 作者:(美)科波特 译者:魏永明 耿岳 钟书毅 Jonahan Corbet早在1981年就开始接触BSD Unix的源代码。那时,科罗拉多大学的一名讲师让他“修正”其中的分页算法。从那时起直到现在。他深入研究了他所遇到的每一个系统,其中包括VAX、Sun、Arden以及x86系统的驱动程序。他在1993年第一次接触Linux系统,从此以后一直从事Linux的开发。Corbet先生是《Linux Weekly News》的创始人和执行主编。他和妻子及两个孩子生活在科罗多州的玻尔得市。 目录 ch00.前言 ch01.第一章 设备驱动程序简介 设备驱动程序的作用 内核功能划分 设备和模块的分类 安全问题 版本编号 许可证条款 加入内核开发社团 本书概要 ch02.第二章 构造和运行模块 设置测试系统 Hello world模块 核心模块与应用程序的对比 编译和装载 内核符号表 预备知识 初始化和关闭 模块参数 在用户空间编写驱动程序 快速参考 ch03.第三章 字符设备驱动程序 scull的设计 主设备号和次设备号 一些重要的数据结构 字符设备的注册 open和release scull的内存使用 read和write 试试新设备 快速参考 ch04.第四章 调试技术 内核中的调试支持 通过打印调试 通过查询调试 通过监视调试 调试系统故障 调试器和相关工具 ch05.第五章 并发和竞态 scull的缺陷 并发及其管理 信号量和互斥体 completiOn 自旋锁 锁陷阱 除了锁之外的办法 快速参考 ch06.第六章 高级字符驱动程序操作 ioctl 阻塞型I/O poll和select 异步通知 定位设备 设备文件的访问控制 快速参考 ch07.第七章 时间、延迟及延缓操作 度量时间差 获取当前时间 延迟执行 内核定时器 tasklet 工作队列 快速参考 ch08.第八章 分配内存 kmalloc函数的内幕 后备高速缓存 get—free—page和相关函数 vmalloc及其辅助函数 per-CPU变量 获取大的缓冲区 快速参考 ch09... ch10... ... ch18...
目录 历史 前言 I. C语言入门 1. 程序的基本概念 1. 程序和编程语言 2. 自然语言和形式语言 3. 程序的调试 4. 第一个程序 2. 常量、变量和表达式 1. 继续Hello World 2. 常量 3. 变量 4. 赋值 5. 表达式 6. 字符类型与字符编码 3. 简单函数 1. 数学函数 2. 自定义函数 3. 形参和实参 4. 全局变量、局部变量和作用域 4. 分支语句 1. if语句 2. if/else语句 3. 布尔代数 4. switch语句 5. 深入理解函数 1. return语句 2. 增量式开发 3. 递归 6. 循环语句 1. while语句 2. do/while语句 3. for语句 4. break和continue语句 5. 嵌套循环 6. goto语句和标号 7. 结构体 1. 复合类型与结构体 2. 数据抽象 3. 数据类型标志 4. 嵌套结构体 8. 数组 1. 数组的基本概念 2. 数组应用实例:统计随机数 3. 数组应用实例:直方图 4. 字符串 5. 多维数组 9. 编码风格 1. 缩进和空白 2. 注释 3. 标识符命名 4. 函数 5. indent工具 10. gdb 1. 单步执行和跟踪函数调用 2. 断点 3. 观察点 4. 段错误 11. 排序与查找 1. 算法的概念 2. 插入排序 3. 算法的时间复杂度分析 4. 归并排序 5. 线性查找 6. 折半查找 12. 栈与队列 1. 数据结构的概念 2. 堆栈 3. 深度优先搜索 4. 队列与广度优先搜索 5. 环形队列 13. 本阶段总结 II. C语言本质 14. 计算机中数的表示 1. 为什么计算机用二进制计数 2. 不同进制之间的换算 3. 整数的加减运算 3.1. Sign and Magnitude表示法 3.2. 1's Complement表示法 3.3. 2's Complement表示法 3.4. 有符号数和无符号数 4. 浮点数 15. 数据类型详解 1. 整型 2. 浮点型 3. 类型转换 3.1. Integer Promotion 3.2. Usual Arithmetic Conversion 3.3. 由赋值产生的类型转换 3.4. 强制类型转换 3.5. 编译器如何处理类型转换 16. 运算符详解 1. 位运算 1.1. 按位与、或、异或、取反运算 1.2. 移位运算 1.3. 掩码 1.4. 异或运算的一些特性 2. 其它运算符 2.1. 复合赋值运算符 2.2. 条件运算符 2.3. 逗号运算符 2.4. sizeof运算符与typedef类型声明 3. Side Effect与Sequence Point 4. 运算符总结 17. 计算机体系结构基础 1. 内存与地址 2. CPU 3. 设备 4. MMU 5. Memory Hierarchy 18. x86汇编程序基础 1. 最简单的汇编程序 2. x86的寄存器 3. 第二个汇编程序 4. 寻址方式 5. ELF文件 5.1. 目标文件 5.2. 可执行文件 19. 汇编与C之间的关系 1. 函数调用 2. main函数和启动例程 3. 变量的存储布局 4. 结构体和联合体 5. C内联汇编 6. volatile限定符 20. 链接详解 1. 多目标文件的链接 2. 定义和声明 2.1. extern和static关键字 2.2. 头文件 2.3. 定义和声明的详细规则 3. 静态库 4. 共享库 4.1. 编译、链接、运行 4.2. 动态链接的过程 4.3. 共享库的命名惯例 5. 虚拟内存管理 21. 预处理 1. 预处理的步骤 2. 宏定义 2.1. 函数式宏定义 2.2. 内联函数 2.3. #、##运算符和可变参数 2.4. 宏展开的步骤 3. 条件预处理指示 4. 其它预处理特性 22. Makefile基础 1. 基本规则 2. 隐含规则和模式规则 3. 变量 4. 自动处理头文件的依赖关系 5. 常用的make命令行选项 23. 指针 1. 指针的基本概念 2. 指针类型的参数和返回值 3. 指针与数组 4. 指针与const限定符 5. 指针与结构体 6. 指向指针的指针与指针数组 7. 指向数组的指针与多维数组 8. 函数类型和函数指针类型 9. 不完全类型和复杂声明 24. 函数接口 1. 本章的预备知识 1.1. strcpy与strncpy 1.2. malloc与free 2. 传入参数与传出参数 3. 两层指针的参数 4. 返回值是指针的情况 5. 回调函数 6. 可变参数 25. C标准库 1. 字符串操作函数 1.1. 初始化字符串 1.2. 取字符串的长度 1.3. 拷贝字符串 1.4. 连接字符串 1.5. 比较字符串 1.6. 搜索字符串 1.7. 分割字符串 2. 标准I/O库函数 2.1. 文件的基本概念 2.2. fopen/fclose 2.3. stdin/stdout/stderr 2.4. errno与perror函数 2.5. 以字节为单位的I/O函数 2.6. 操作读写位置的函数 2.7. 以字符串为单位的I/O函数 2.8. 以记录为单位的I/O函数 2.9. 格式化I/O函数 2.10. C标准库的I/O缓冲区 2.11. 本节综合练习 3. 数值字符串转换函数 4. 分配内存的函数 26. 链表、二叉树和哈希表 1. 链表 1.1. 单链表 1.2. 双向链表 1.3. 静态链表 1.4. 本节综合练习 2. 二叉树 2.1. 二叉树的基本概念 2.2. 排序二叉树 3. 哈希表 27. 本阶段总结 III. Linux系统编程 28. 文件与I/O 1. 汇编程序的Hello world 2. C标准I/O库函数与Unbuffered I/O函数 3. open/close 4. read/write 5. lseek 6. fcntl 7. ioctl 8. mmap 29. 文件系统 1. 引言 2. ext2文件系统 2.1. 总体存储布局 2.2. 实例剖析 2.3. 数据块寻址 2.4. 文件和目录操作的系统函数 3. VFS 3.1. 内核数据结构 3.2. dup和dup2函数 30. 进程 1. 引言 2. 环境变量 3. 进程控制 3.1. fork函数 3.2. exec函数 3.3. wait和waitpid函数 4. 进程间通信 4.1. 管道 4.2. 其它IPC机制 5. 练习:实现简单的Shell 31. Shell脚本 1. Shell的历史 2. Shell如何执行命令 2.1. 执行交互式命令 2.2. 执行脚本 3. Shell的基本语法 3.1. 变量 3.2. 文件名代换(Globbing):* ? [] 3.3. 命令代换:`或 $() 3.4. 算术代换:$(()) 3.5. 转义字符\ 3.6. 单引号 3.7. 双引号 4. bash启动脚本 4.1. 作为交互登录Shell启动,或者使用--login参数启动 4.2. 以交互非登录Shell启动 4.3. 非交互启动 4.4. 以sh命令启动 5. Shell脚本语法 5.1. 条件测试:test [ 5.2. if/then/elif/else/fi 5.3. case/esac 5.4. for/do/done 5.5. while/do/done 5.6. 位置参数和特殊变量 5.7. 函数 6. Shell脚本的调试方法 32. 正则表达式 1. 引言 2. 基本语法 3. sed 4. awk 5. 练习:在C语言中使用正则表达式 33. 信号 1. 信号的基本概念 2. 产生信号 2.1. 通过终端按键产生信号 2.2. 调用系统函数向进程发信号 2.3. 由软件条件产生信号 3. 阻塞信号 3.1. 信号在内核中的表示 3.2. 信号集操作函数 3.3. sigprocmask 3.4. sigpending 4. 捕捉信号 4.1. 内核如何实现信号的捕捉 4.2. sigaction 4.3. pause 4.4. 可重入函数 4.5. sig_atomic_t类型与volatile限定符 4.6. 竞态条件与sigsuspend函数 4.7. 关于SIGCHLD信号 34. 终端、作业控制与守护进程 1. 终端 1.1. 终端的基本概念 1.2. 终端登录过程 1.3. 网络登录过程 2. 作业控制 2.1. Session与进程组 2.2. 与作业控制有关的信号 3. 守护进程 35. 线程 1. 线程的概念 2. 线程控制 2.1. 创建线程 2.2. 终止线程 3. 线程间同步 3.1. mutex 3.2. Condition Variable 3.3. Semaphore 3.4. 其它线程间同步机制 4. 编程练习 36. TCP/IP协议基础 1. TCP/IP协议栈与数据包封装 2. 以太网(RFC 894)帧格式 3. ARP数据报格式 4. IP数据报格式 5. IP地址与路由 6. UDP段格式 7. TCP协议 7.1. 段格式 7.2. 通讯时序 7.3. 流量控制 37. socket编程 1. 预备知识 1.1. 网络字节序 1.2. socket地址的数据类型及相关函数 2. 基于TCP协议的网络程序 2.1. 最简单的TCP网络程序 2.2. 错误处理与读写控制 2.3. 把client改为交互式输入 2.4. 使用fork并发处理多个client的请求 2.5. setsockopt 2.6. 使用select 3. 基于UDP协议的网络程序 4. UNIX Domain Socket IPC 5. 练习:实现简单的Web服务器 5.1. 基本HTTP协议 5.2. 执行CGI程序 A. 字符编码 1. ASCII码 2. Unicode和UTF-8 3. 在Linux C编程中使用Unicode和UTF-8 B. GNU Free Documentation License Version 1.3, 3 November 2008 参考书目 索引
文将对 Linux™ 程序员可以使用的内存管理技术进行概述,虽然关注的重点是 C 语言,但同样也适用于其他语言。文中将为您提供如何管理内存的细节,然后将进一步展示如何手工管理内存,如何使用引用计数或者内存池来半手工地管理内存,以及如何使用垃圾收集自动管理内存。 为什么必须管理内存 内存管理是计算机编程最为基本的领域之一。在很多脚本语言中,您不必担心内存是如何管理的,这并不能使得内存管理的重要性有一点点降低。对实际编程来说,理解您的内存管理器的能力与局限性至关重要。在大部分系统语言中,比如 C 和 C++,您必须进行内存管理。本文将介绍手工的、半手工的以及自动的内存管理实践的基本概念。 追溯到在 Apple II 上进行汇编语言编程的时代,那时内存管理还不是个大问题。您实际上在运行整个系统。系统有多少内存,您就有多少内存。您甚至不必费心思去弄明白它有多少内存,因为每一台机器的内存数量都相同。所以,如果内存需要非常固定,那么您只需要选择一个内存范围并使用它即可。 不过,即使是在这样一个简单的计算机中,您也会有问题,尤其是当您不知道程序的每个部分将需要多少内存时。如果您的空间有限,而内存需求是变化的,那么您需要一些方法来满足这些需求: 确定您是否有足够的内存来处理数据。 从可用的内存中获取一部分内存。 向可用内存池(pool)中返回部分内存,以使其可以由程序的其他部分或者其他程序使用。 实现这些需求的程序库称为 分配程序(allocators),因为它们负责分配和回收内存。程序的动态性越强,内存管理就越重要,您的内存分配程序的选择也就更重要。让我们来了解可用于内存管理的不同方法,它们的好处与不足,以及它们最适用的情形。 回页首 C 风格的内存分配程序 C 编程语言提供了两个函数来满足我们的三个需求: malloc:该函数分配给定的字节数,并返回一个指向它们的指针。如果没有足够的可用内存,那么它返回一个空指针。 free:该函数获得指向由 malloc 分配的内存片段的指针,并将其释放,以便以后的程序或操作系统使用(实际上,一些 malloc 实现只能将内存归还给程序,而无法将内存归还给操作系统)。 物理内存和虚拟内存 要理解内存在程序中是如何分配的,首先需要理解如何将内存从操作系统分配给程序。计算机上的每一个进程都认为自己可以访问所有的物理内存。显然,由于同时在运行多个程序,所以每个进程不可能拥有全部内存。实际上,这些进程使用的是 虚拟内存。 只是作为一个例子,让我们假定您的程序正在访问地址为 629 的内存。不过,虚拟内存系统不需要将其存储在位置为 629 的 RAM 中。实际上,它甚至可以不在 RAM 中 —— 如果物理 RAM 已经满了,它甚至可能已经被转移到硬盘上!由于这类地址不必反映内存所在的物理位置,所以它们被称为虚拟内存。操作系统维持着一个虚拟地址到物理地址的转换的表,以便计算机硬件可以正确地响应地址请求。并且,如果地址在硬盘上而不是在 RAM 中,那么操作系统将暂时停止您的进程,将其他内存转存到硬盘中,从硬盘上加载被请求的内存,然后再重新启动您的进程。这样,每个进程都获得了自己可以使用的地址空间,可以访问比您物理上安装的内存更多的内存。 在 32-位 x86 系统上,每一个进程可以访问 4 GB 内存。现在,大部分人的系统上并没有 4 GB 内存,即使您将 swap 也算上, 每个进程所使用的内存也肯定少于 4 GB。因此,当加载一个进程时,它会得到一个取决于某个称为 系统中断点(system break)的特定地址的初始内存分配。该地址之后是未被映射的内存 —— 用于在 RAM 或者硬盘中没有分配相应物理位置的内存。因此,如果一个进程运行超出了它初始分配的内存,那么它必须请求操作系统“映射进来(map in)”更多的内存。(映射是一个表示一一对应关系的数学术语 —— 当内存的虚拟地址有一个对应的物理地址来存储内存内容时,该内存将被映射。) 基于 UNIX 的系统有两个可映射到附加内存中的基本系统调用: brk: brk() 是一个非常简单的系统调用。还记得系统中断点吗?该位置是进程映射的内存边界。 brk() 只是简单地将这个位置向前或者向后移动,就可以向进程添加内存或者从进程取走内存。 mmap: mmap(),或者说是“内存映像”,类似于 brk(),但是更为灵活。首先,它可以映射任何位置的内存,而不单单只局限于进程。其次,它不仅可以将虚拟地址映射到物理的 RAM 或者 swap,它还可以将它们映射到文件和文件位置,这样,读写内存将对文件中的数据进行读写。不过,在这里,我们只关心 mmap 向进程添加被映射的内存的能力。 munmap() 所做的事情与 mmap() 相反。 如您所见, brk() 或者 mmap() 都可以用来向我们的进程添加额外的虚拟内存。在我们的例子中将使用 brk(),因为它更简单,更通用。 实现一个简单的分配程序 如果您曾经编写过很多 C 程序,那么您可能曾多次使用过 malloc() 和 free()。不过,您可能没有用一些时间去思考它们在您的操作系统中是如何实现的。本节将向您展示 malloc 和 free 的一个最简化实现的代码,来帮助说明管理内存时都涉及到了哪些事情。 要试着运行这些示例,需要先 复制本代码清单,并将其粘贴到一个名为 malloc.c 的文件中。接下来,我将一次一个部分地对该清单进行解释。 在大部分操作系统中,内存分配由以下两个简单的函数来处理: void *malloc(long numbytes):该函数负责分配 numbytes 大小的内存,并返回指向第一个字节的指针。 void free(void *firstbyte):如果给定一个由先前的 malloc 返回的指针,那么该函数会将分配的空间归还给进程的“空闲空间”。 malloc_init 将是初始化内存分配程序的函数。它要完成以下三件事:将分配程序标识为已经初始化,找到系统中最后一个有效内存地址,然后建立起指向我们管理的内存的指针。这三个变量都是全局变量: 清单 1. 我们的简单分配程序的全局变量 int has_initialized = 0; void *managed_memory_start; void *last_valid_address; 如前所述,被映射的内存的边界(最后一个有效地址)常被称为系统中断点或者 当前中断点。在很多 UNIX® 系统中,为了指出当前系统中断点,必须使用 sbrk(0) 函数。 sbrk 根据参数中给出的字节数移动当前系统中断点,然后返回新的系统中断点。使用参数 0 只是返回当前中断点。这里是我们的 malloc 初始化代码,它将找到当前中断点并初始化我们的变量: 清单 2. 分配程序初始化函数 /* Include the sbrk function */ #include void malloc_init() { /* grab the last valid address from the OS */ last_valid_address = sbrk(0); /* we don't have any memory to manage yet, so *just set the beginning to be last_valid_address */ managed_memory_start = last_valid_address; /* Okay, we're initialized and ready to go */ has_initialized = 1; } 现在,为了完全地管理内存,我们需要能够追踪要分配和回收哪些内存。在对内存块进行了 free 调用之后,我们需要做的是诸如将它们标记为未被使用的等事情,并且,在调用 malloc 时,我们要能够定位未被使用的内存块。因此, malloc 返回的每块内存的起始处首先要有这个结构: 清单 3. 内存控制块结构定义 struct mem_control_block { int is_available; int size; }; 现在,您可能会认为当程序调用 malloc 时这会引发问题 —— 它们如何知道这个结构?答案是它们不必知道;在返回指针之前,我们会将其移动到这个结构之后,把它隐藏起来。这使得返回的指针指向没有用于任何其他用途的内存。那样,从调用程序的角度来看,它们所得到的全部是空闲的、开放的内存。然后,当通过 free() 将该指针传递回来时,我们只需要倒退几个内存字节就可以再次找到这个结构。 在讨论分配内存之前,我们将先讨论释放,因为它更简单。为了释放内存,我们必须要做的惟一一件事情就是,获得我们给出的指针,回退 sizeof(struct mem_control_block) 个字节,并将其标记为可用的。这里是对应的代码: 清单 4. 解除分配函数 void free(void *firstbyte) { struct mem_control_block *mcb; /* Backup from the given pointer to find the * mem_control_block */ mcb = firstbyte - sizeof(struct mem_control_block); /* Mark the block as being available */ mcb->is_available = 1; /* That's It! We're done. */ return; } 如您所见,在这个分配程序中,内存的释放使用了一个非常简单的机制,在固定时间内完成内存释放。分配内存稍微困难一些。以下是该算法的略述: 清单 5. 主分配程序的伪代码 1. If our allocator has not been initialized, initialize it. 2. Add sizeof(struct mem_control_block) to the size requested. 3. start at managed_memory_start. 4. Are we at last_valid address? 5. If we are: A. We didn't find any existing space that was large enough -- ask the operating system for more and return that. 6. Otherwise: A. Is the current space available (check is_available from the mem_control_block)? B. If it is: i) Is it large enough (check "size" from the mem_control_block)? ii) If so: a. Mark it as unavailable b. Move past mem_control_block and return the pointer iii) Otherwise: a. Move forward "size" bytes b. Go back go step 4 C. Otherwise: i) Move forward "size" bytes ii) Go back to step 4 我们主要使用连接的指针遍历内存来寻找开放的内存块。这里是代码: 清单 6. 主分配程序 void *malloc(long numbytes) { /* Holds where we are looking in memory */ void *current_location; /* This is the same as current_location, but cast to a * memory_control_block */ struct mem_control_block *current_location_mcb; /* This is the memory location we will return. It will * be set to 0 until we find something suitable */ void *memory_location; /* Initialize if we haven't already done so */ if(! has_initialized) { malloc_init(); } /* The memory we search for has to include the memory * control block, but the users of malloc don't need * to know this, so we'll just add it in for them. */ numbytes = numbytes + sizeof(struct mem_control_block); /* Set memory_location to 0 until we find a suitable * location */ memory_location = 0; /* Begin searching at the start of managed memory */ current_location = managed_memory_start; /* Keep going until we have searched all allocated space */ while(current_location != last_valid_address) { /* current_location and current_location_mcb point * to the same address. However, current_location_mcb * is of the correct type, so we can use it as a struct. * current_location is a void pointer so we can use it * to calculate addresses. */ current_location_mcb = (struct mem_control_block *)current_location; if(current_location_mcb->is_available) { if(current_location_mcb->size >= numbytes) { /* Woohoo! We've found an open, * appropriately-size location. */ /* It is no longer available */ current_location_mcb->is_available = 0; /* We own it */ memory_location = current_location; /* Leave the loop */ break; } } /* If we made it here, it's because the Current memory * block not suitable; move to the next one */ current_location = current_location + current_location_mcb->size; } /* If we still don't have a valid location, we'll * have to ask the operating system for more memory */ if(! memory_location) { /* Move the program break numbytes further */ sbrk(numbytes); /* The new memory will be where the last valid * address left off */ memory_location = last_valid_address; /* We'll move the last valid address forward * numbytes */ last_valid_address = last_valid_address + numbytes; /* We need to initialize the mem_control_block */ current_location_mcb = memory_location; current_location_mcb->is_available = 0; current_location_mcb->size = numbytes; } /* Now, no matter what (well, except for error conditions), * memory_location has the address of the memory, including * the mem_control_block */ /* Move the pointer past the mem_control_block */ memory_location = memory_location + sizeof(struct mem_control_block); /* Return the pointer */ return memory_location; } 这就是我们的内存管理器。现在,我们只需要构建它,并在程序中使用它即可。 运行下面的命令来构建 malloc 兼容的分配程序(实际上,我们忽略了 realloc() 等一些函数,不过, malloc() 和 free() 才是最主要的函数): 清单 7. 编译分配程序 gcc -shared -fpic malloc.c -o malloc.so 该程序将生成一个名为 malloc.so 的文件,它是一个包含有我们的代码的共享库。 在 UNIX 系统中,现在您可以用您的分配程序来取代系统的 malloc(),做法如下: 清单 8. 替换您的标准的 malloc LD_PRELOAD=/path/to/malloc.so export LD_PRELOAD LD_PRELOAD 环境变量使动态链接器在加载任何可执行程序之前,先加载给定的共享库的符号。它还为特定库中的符号赋予优先权。因此,从现在起,该会话中的任何应用程序都将使用我们的 malloc(),而不是只有系统的应用程序能够使用。有一些应用程序不使用 malloc(),不过它们是例外。其他使用 realloc() 等其他内存管理函数的应用程序,或者错误地假定 malloc() 内部行为的那些应用程序,很可能会崩溃。ash shell 似乎可以使用我们的新 malloc() 很好地工作。 如果您想确保 malloc() 正在被使用,那么您应该通过向函数的入口点添加 write() 调用来进行测试。 我们的内存管理器在很多方面都还存在欠缺,但它可以有效地展示内存管理需要做什么事情。它的某些缺点包括: 由于它对系统中断点(一个全局变量)进行操作,所以它不能与其他分配程序或者 mmap 一起使用。 当分配内存时,在最坏的情形下,它将不得不遍历 全部进程内存;其中可能包括位于硬盘上的很多内存,这意味着操作系统将不得不花时间去向硬盘移入数据和从硬盘中移出数据。 没有很好的内存不足处理方案( malloc 只假定内存分配是成功的)。 它没有实现很多其他的内存函数,比如 realloc()。 由于 sbrk() 可能会交回比我们请求的更多的内存,所以在堆(heap)的末端会遗漏一些内存。 虽然 is_available 标记只包含一位信息,但它要使用完整的 4-字节 的字。 分配程序不是线程安全的。 分配程序不能将空闲空间拼合为更大的内存块。 分配程序的过于简单的匹配算法会导致产生很多潜在的内存碎片。 我确信还有很多其他问题。这就是为什么它只是一个例子! 其他 malloc 实现 malloc() 的实现有很多,这些实现各有优点与缺点。在设计一个分配程序时,要面临许多需要折衷的选择,其中包括: 分配的速度。 回收的速度。 有线程的环境的行为。 内存将要被用光时的行为。 局部缓存。 簿记(Bookkeeping)内存开销。 虚拟内存环境中的行为。 小的或者大的对象。 实时保证。 每一个实现都有其自身的优缺点集合。在我们的简单的分配程序中,分配非常慢,而回收非常快。另外,由于它在使用虚拟内存系统方面较差,所以它最适于处理大的对象。 还有其他许多分配程序可以使用。其中包括: Doug Lea Malloc:Doug Lea Malloc 实际上是完整的一组分配程序,其中包括 Doug Lea 的原始分配程序,GNU libc 分配程序和 ptmalloc。 Doug Lea 的分配程序有着与我们的版本非常类似的基本结构,但是它加入了索引,这使得搜索速度更快,并且可以将多个没有被使用的块组合为一个大的块。它还支持缓存,以便更快地再次使用最近释放的内存。 ptmalloc 是 Doug Lea Malloc 的一个扩展版本,支持多线程。在本文后面的 参考资料部分中,有一篇描述 Doug Lea 的 Malloc 实现的文章。 BSD Malloc:BSD Malloc 是随 4.2 BSD 发行的实现,包含在 FreeBSD 之中,这个分配程序可以从预先确实大小的对象构成的池中分配对象。它有一些用于对象大小的 size 类,这些对象的大小为 2 的若干次幂减去某一常数。所以,如果您请求给定大小的一个对象,它就简单地分配一个与之匹配的 size 类。这样就提供了一个快速的实现,但是可能会浪费内存。在 参考资料部分中,有一篇描述该实现的文章。 Hoard:编写 Hoard 的目标是使内存分配在多线程环境中进行得非常快。因此,它的构造以锁的使用为中心,从而使所有进程不必等待分配内存。它可以显著地加快那些进行很多分配和回收的多线程进程的速度。在 参考资料部分中,有一篇描述该实现的文章。 众多可用的分配程序中最有名的就是上述这些分配程序。如果您的程序有特别的分配需求,那么您可能更愿意编写一个定制的能匹配您的程序内存分配方式的分配程序。不过,如果不熟悉分配程序的设计,那么定制分配程序通常会带来比它们解决的问题更多的问题。要获得关于该主题的适当的介绍,请参阅 Donald Knuth 撰写的 The Art of Computer Programming Volume 1: Fundamental Algorithms 中的第 2.5 节“Dynamic Storage Allocation”(请参阅 参考资料中的链接)。它有点过时,因为它没有考虑虚拟内存环境,不过大部分算法都是基于前面给出的函数。 在 C++ 中,通过重载 operator new(),您可以以每个类或者每个模板为单位实现自己的分配程序。在 Andrei Alexandrescu 撰写的 Modern C++ Design 的第 4 章(“Small Object Allocation”)中,描述了一个小对象分配程序(请参阅 参考资料中的链接)。 基于 malloc() 的内存管理的缺点 不只是我们的内存管理器有缺点,基于 malloc() 的内存管理器仍然也有很多缺点,不管您使用的是哪个分配程序。对于那些需要保持长期存储的程序使用 malloc() 来管理内存可能会非常令人失望。如果您有大量的不固定的内存引用,经常难以知道它们何时被释放。生存期局限于当前函数的内存非常容易管理,但是对于生存期超出该范围的内存来说,管理内存则困难得多。而且,关于内存管理是由进行调用的程序还是由被调用的函数来负责这一问题,很多 API 都不是很明确。 因为管理内存的问题,很多程序倾向于使用它们自己的内存管理规则。C++ 的异常处理使得这项任务更成问题。有时好像致力于管理内存分配和清理的代码比实际完成计算任务的代码还要多!因此,我们将研究内存管理的其他选择。 回页首 半自动内存管理策略 引用计数 引用计数是一种 半自动(semi-automated)的内存管理技术,这表示它需要一些编程支持,但是它不需要您确切知道某一对象何时不再被使用。引用计数机制为您完成内存管理任务。 在引用计数中,所有共享的数据结构都有一个域来包含当前活动“引用”结构的次数。当向一个程序传递一个指向某个数据结构指针时,该程序会将引用计数增加 1。实质上,您是在告诉数据结构,它正在被存储在多少个位置上。然后,当您的进程完成对它的使用后,该程序就会将引用计数减少 1。结束这个动作之后,它还会检查计数是否已经减到零。如果是,那么它将释放内存。 这样做的好处是,您不必追踪程序中某个给定的数据结构可能会遵循的每一条路径。每次对其局部的引用,都将导致计数的适当增加或减少。这样可以防止在使用数据结构时释放该结构。不过,当您使用某个采用引用计数的数据结构时,您必须记得运行引用计数函数。另外,内置函数和第三方的库不会知道或者可以使用您的引用计数机制。引用计数也难以处理发生循环引用的数据结构。 要实现引用计数,您只需要两个函数 —— 一个增加引用计数,一个减少引用计数并当计数减少到零时释放内存。 一个示例引用计数函数集可能看起来如下所示: 清单 9. 基本的引用计数函数 /* Structure Definitions*/ /* Base structure that holds a refcount */ struct refcountedstruct { int refcount; } /* All refcounted structures must mirror struct * refcountedstruct for their first variables */ /* Refcount maintenance functions */ /* Increase reference count */ void REF(void *data) { struct refcountedstruct *rstruct; rstruct = (struct refcountedstruct *) data; rstruct->refcount++; } /* Decrease reference count */ void UNREF(void *data) { struct refcountedstruct *rstruct; rstruct = (struct refcountedstruct *) data; rstruct->refcount--; /* Free the structure if there are no more users */ if(rstruct->refcount == 0) { free(rstruct); } } REF 和 UNREF 可能会更复杂,这取决于您想要做的事情。例如,您可能想要为多线程程序增加锁,那么您可能想扩展 refcountedstruct,使它同样包含一个指向某个在释放内存之前要调用的函数的指针(类似于面向对象语言中的析构函数 —— 如果您的结构中包含这些指针,那么这是 必需的)。 当使用 REF 和 UNREF 时,您需要遵守这些指针的分配规则: UNREF 分配前左端指针(left-hand-side pointer)指向的值。 REF 分配后左端指针(left-hand-side pointer)指向的值。 在传递使用引用计数的结构的函数中,函数需要遵循以下这些规则: 在函数的起始处 REF 每一个指针。 在函数的结束处 UNREF 第一个指针。 以下是一个使用引用计数的生动的代码示例: 清单 10. 使用引用计数的示例 /* EXAMPLES OF USAGE */ /* Data type to be refcounted */ struct mydata { int refcount; /* same as refcountedstruct */ int datafield1; /* Fields specific to this struct */ int datafield2; /* other declarations would go here as appropriate */ }; /* Use the functions in code */ void dosomething(struct mydata *data) { REF(data); /* Process data */ /* when we are through */ UNREF(data); } struct mydata *globalvar1; /* Note that in this one, we don't decrease the * refcount since we are maintaining the reference * past the end of the function call through the * global variable */ void storesomething(struct mydata *data) { REF(data); /* passed as a parameter */ globalvar1 = data; REF(data); /* ref because of Assignment */ UNREF(data); /* Function finished */ } 由于引用计数是如此简单,大部分程序员都自已去实现它,而不是使用库。不过,它们依赖于 malloc 和 free 等低层的分配程序来实际地分配和释放它们的内存。 在 Perl 等高级语言中,进行内存管理时使用引用计数非常广泛。在这些语言中,引用计数由语言自动地处理,所以您根本不必担心它,除非要编写扩展模块。由于所有内容都必须进行引用计数,所以这会对速度产生一些影响,但它极大地提高了编程的安全性和方便性。以下是引用计数的益处: 实现简单。 易于使用。 由于引用是数据结构的一部分,所以它有一个好的缓存位置。 不过,它也有其不足之处: 要求您永远不要忘记调用引用计数函数。 无法释放作为循环数据结构的一部分的结构。 减缓几乎每一个指针的分配。 尽管所使用的对象采用了引用计数,但是当使用异常处理(比如 try 或 setjmp()/ longjmp())时,您必须采取其他方法。 需要额外的内存来处理引用。 引用计数占用了结构中的第一个位置,在大部分机器中最快可以访问到的就是这个位置。 在多线程环境中更慢也更难以使用。 C++ 可以通过使用 智能指针(smart pointers)来容忍程序员所犯的一些错误,智能指针可以为您处理引用计数等指针处理细节。不过,如果不得不使用任何先前的不能处理智能指针的代码(比如对 C 库的联接),实际上,使用它们的后果通实比不使用它们更为困难和复杂。因此,它通常只是有益于纯 C++ 项目。如果您想使用智能指针,那么您实在应该去阅读 Alexandrescu 撰写的 Modern C++ Design 一书中的“Smart Pointers”那一章。 内存池 内存池是另一种半自动内存管理方法。内存池帮助某些程序进行自动内存管理,这些程序会经历一些特定的阶段,而且每个阶段中都有分配给进程的特定阶段的内存。例如,很多网络服务器进程都会分配很多针对每个连接的内存 —— 内存的最大生存期限为当前连接的存在期。Apache 使用了池式内存(pooled memory),将其连接拆分为各个阶段,每个阶段都有自己的内存池。在结束每个阶段时,会一次释放所有内存。 在池式内存管理中,每次内存分配都会指定内存池,从中分配内存。每个内存池都有不同的生存期限。在 Apache 中,有一个持续时间为服务器存在期的内存池,还有一个持续时间为连接的存在期的内存池,以及一个持续时间为请求的存在期的池,另外还有其他一些内存池。因此,如果我的一系列函数不会生成比连接持续时间更长的数据,那么我就可以完全从连接池中分配内存,并知道在连接结束时,这些内存会被自动释放。另外,有一些实现允许注册 清除函数(cleanup functions),在清除内存池之前,恰好可以调用它,来完成在内存被清理前需要完成的其他所有任务(类似于面向对象中的析构函数)。 要在自己的程序中使用池,您既可以使用 GNU libc 的 obstack 实现,也可以使用 Apache 的 Apache Portable Runtime。GNU obstack 的好处在于,基于 GNU 的 Linux 发行版本中默认会包括它们。Apache Portable Runtime 的好处在于它有很多其他工具,可以处理编写多平台服务器软件所有方面的事情。要深入了解 GNU obstack 和 Apache 的池式内存实现,请参阅 参考资料部分中指向这些实现的文档的链接。 下面的假想代码列表展示了如何使用 obstack: 清单 11. obstack 的示例代码 #include #include /* Example code listing for using obstacks */ /* Used for obstack macros (xmalloc is a malloc function that exits if memory is exhausted */ #define obstack_chunk_alloc xmalloc #define obstack_chunk_free free /* Pools */ /* Only permanent allocations should go in this pool */ struct obstack *global_pool; /* This pool is for per-connection data */ struct obstack *connection_pool; /* This pool is for per-request data */ struct obstack *request_pool; void allocation_failed() { exit(1); } int main() { /* Initialize Pools */ global_pool = (struct obstack *) xmalloc (sizeof (struct obstack)); obstack_init(global_pool); connection_pool = (struct obstack *) xmalloc (sizeof (struct obstack)); obstack_init(connection_pool); request_pool = (struct obstack *) xmalloc (sizeof (struct obstack)); obstack_init(request_pool); /* Set the error handling function */ obstack_alloc_failed_handler = &allocation_failed; /* Server main loop */ while(1) { wait_for_connection(); /* We are in a connection */ while(more_requests_available()) { /* Handle request */ handle_request(); /* Free all of the memory allocated * in the request pool */ obstack_free(request_pool, NULL); } /* We're finished with the connection, time * to free that pool */ obstack_free(connection_pool, NULL); } } int handle_request() { /* Be sure that all object allocations are allocated * from the request pool */ int bytes_i_need = 400; void *data1 = obstack_alloc(request_pool, bytes_i_need); /* Do stuff to process the request */ /* return */ return 0; } 基本上,在操作的每一个主要阶段结束之后,这个阶段的 obstack 会被释放。不过,要注意的是,如果一个过程需要分配持续时间比当前阶段更长的内存,那么它也可以使用更长期限的 obstack,比如连接或者全局内存。传递给 obstack_free() 的 NULL 指出它应该释放 obstack 的全部内容。可以用其他的值,但是它们通常不怎么实用。 使用池式内存分配的益处如下所示: 应用程序可以简单地管理内存。 内存分配和回收更快,因为每次都是在一个池中完成的。分配可以在 O(1) 时间内完成,释放内存池所需时间也差不多(实际上是 O(n) 时间,不过在大部分情况下会除以一个大的因数,使其变成 O(1))。 可以预先分配错误处理池(Error-handling pools),以便程序在常规内存被耗尽时仍可以恢复。 有非常易于使用的标准实现。 池式内存的缺点是: 内存池只适用于操作可以分阶段的程序。 内存池通常不能与第三方库很好地合作。 如果程序的结构发生变化,则不得不修改内存池,这可能会导致内存管理系统的重新设计。 您必须记住需要从哪个池进行分配。另外,如果在这里出错,就很难捕获该内存池。 回页首 垃圾收集 垃圾收集(Garbage collection)是全自动地检测并移除不再使用的数据对象。垃圾收集器通常会在当可用内存减少到少于一个具体的阈值时运行。通常,它们以程序所知的可用的一组“基本”数据 —— 栈数据、全局变量、寄存器 —— 作为出发点。然后它们尝试去追踪通过这些数据连接到每一块数据。收集器找到的都是有用的数据;它没有找到的就是垃圾,可以被销毁并重新使用这些无用的数据。为了有效地管理内存,很多类型的垃圾收集器都需要知道数据结构内部指针的规划,所以,为了正确运行垃圾收集器,它们必须是语言本身的一部分。 收集器的类型 复制(copying): 这些收集器将内存存储器分为两部分,只允许数据驻留在其中一部分上。它们定时地从“基本”的元素开始将数据从一部分复制到另一部分。内存新近被占用的部分现在成为活动的,另一部分上的所有内容都认为是垃圾。另外,当进行这项复制操作时,所有指针都必须被更新为指向每个内存条目的新位置。因此,为使用这种垃圾收集方法,垃圾收集器必须与编程语言集成在一起。 标记并清理(Mark and sweep):每一块数据都被加上一个标签。不定期的,所有标签都被设置为 0,收集器从“基本”的元素开始遍历数据。当它遇到内存时,就将标签标记为 1。最后没有被标记为 1 的所有内容都认为是垃圾,以后分配内存时会重新使用它们。 增量的(Incremental):增量垃圾收集器不需要遍历全部数据对象。因为在收集期间的突然等待,也因为与访问所有当前数据相关的缓存问题(所有内容都不得不被页入(page-in)),遍历所有内存会引发问题。增量收集器避免了这些问题。 保守的(Conservative):保守的垃圾收集器在管理内存时不需要知道与数据结构相关的任何信息。它们只查看所有数据类型,并假定它们 可以全部都是指针。所以,如果一个字节序列可以是一个指向一块被分配的内存的指针,那么收集器就将其标记为正在被引用。有时没有被引用的内存会被收集,这样会引发问题,例如,如果一个整数域中包含一个值,该值是已分配内存的地址。不过,这种情况极少发生,而且它只会浪费少量内存。保守的收集器的优势是,它们可以与任何编程语言相集成。 Hans Boehm 的保守垃圾收集器是可用的最流行的垃圾收集器之一,因为它是免费的,而且既是保守的又是增量的,可以使用 --enable-redirect-malloc 选项来构建它,并且可以将它用作系统分配程序的简易替代者(drop-in replacement)(用 malloc/ free 代替它自己的 API)。实际上,如果这样做,您就可以使用与我们在示例分配程序中所使用的相同的 LD_PRELOAD 技巧,在系统上的几乎任何程序中启用垃圾收集。如果您怀疑某个程序正在泄漏内存,那么您可以使用这个垃圾收集器来控制进程。在早期,当 Mozilla 严重地泄漏内存时,很多人在其中使用了这项技术。这种垃圾收集器既可以在 Windows® 下运行,也可以在 UNIX 下运行。 垃圾收集的一些优点: 您永远不必担心内存的双重释放或者对象的生命周期。 使用某些收集器,您可以使用与常规分配相同的 API。 其缺点包括: 使用大部分收集器时,您都无法干涉何时释放内存。 在多数情况下,垃圾收集比其他形式的内存管理更慢。 垃圾收集错误引发的缺陷难于调试。 如果您忘记将不再使用的指针设置为 null,那么仍然会有内存泄漏。 回页首 结束语 一切都需要折衷:性能、易用、易于实现、支持线程的能力等,这里只列出了其中的一些。为了满足项目的要求,有很多内存管理模式可以供您使用。每种模式都有大量的实现,各有其优缺点。对很多项目来说,使用编程环境默认的技术就足够了,不过,当您的项目有特殊的需要时,了解可用的选择将会有帮助。下表对比了本文中涉及的内存管理策略。 表 1. 内存分配策略的对比 策略 分配速度 回收速度 局部缓存 易用性 通用性 实时可用 SMP 线程友好 定制分配程序 取决于实现 取决于实现 取决于实现 很难 无 取决于实现 取决于实现 简单分配程序 内存使用少时较快 很快 差 容易 高 否 否 GNU malloc 中 快 中 容易 高 否 中 Hoard 中 中 中 容易 高 否 是 引用计数 N/A N/A 非常好 中 中 是(取决于 malloc 实现) 取决于实现 池 中 非常快 极好 中 中 是(取决于 malloc 实现) 取决于实现 垃圾收集 中(进行收集时慢) 中 差 中 中 否 几乎不 增量垃圾收集 中 中 中 中 中 否 几乎不 增量保守垃圾收集 中 中 中 容易 高 否 几乎不 参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文。 Web 上的文档 GNU C Library 手册的 obstacks 部分 提供了 obstacks 编程接口。 Apache Portable Runtime 文档 描述了它们的池式分配程序的接口。 基本的分配程序 Doug Lea 的 Malloc 是最流行的内存分配程序之一。 BSD Malloc 用于大部分基于 BSD 的系统中。 ptmalloc 起源于 Doug Lea 的 malloc,用于 GLIBC 之中。 Hoard 是一个为多线程应用程序优化的 malloc 实现。 GNU Memory-Mapped Malloc(GDB 的组成部分) 是一个基于 mmap() 的 malloc 实现。 池式分配程序 GNU Obstacks(GNU Libc 的组成部分)是安装最多的池式分配程序,因为在每一个基于 glibc 的系统中都有它。 Apache 的池式分配程序(Apache Portable Runtime 中) 是应用最为广泛的池式分配程序。 Squid 有其自己的池式分配程序。 NetBSD 也有其自己的池式分配程序。 talloc 是一个池式分配程序,是 Samba 的组成部分。 智能指针和定制分配程序 Loki C++ Library 有很多为 C++ 实现的通用模式,包括智能指针和一个定制的小对象分配程序。 垃圾收集器 Hahns Boehm Conservative Garbage Collector 是最流行的开源垃圾收集器,它可以用于常规的 C/C++ 程序。 关于现代操作系统中的虚拟内存的文章 Marshall Kirk McKusick 和 Michael J. Karels 合著的 A New Virtual Memory Implementation for Berkeley UNIX 讨论了 BSD 的 VM 系统。 Mel Gorman's Linux VM Documentation 讨论了 Linux VM 系统。 关于 malloc 的文章 Poul-Henning Kamp 撰写的 Malloc in Modern Virtual Memory Environments 讨论的是 malloc 以及它如何与 BSD 虚拟内存交互。 Berger、McKinley、Blumofe 和 Wilson 合著的 Hoard -- a Scalable Memory Allocator for Multithreaded Environments 讨论了 Hoard 分配程序的实现。 Marshall Kirk McKusick 和 Michael J. Karels 合著的 Design of a General Purpose Memory Allocator for the 4.3BSD UNIX Kernel 讨论了内核级的分配程序。 Doug Lea 撰写的 A Memory Allocator 给出了一个关于设计和实现分配程序的概述,其中包括设计选择与折衷。 Emery D. Berger 撰写的 Memory Management for High-Performance Applications 讨论的是定制内存管理以及它如何影响高性能应用程序。 关于定制分配程序的文章 Doug Lea 撰写的 Some Storage Management Techniques for Container Classes 描述的是为 C++ 类编写定制分配程序。 Berger、Zorn 和 McKinley 合著的 Composing High-Performance Memory Allocators 讨论了如何编写定制分配程序来加快具体工作的速度。 Berger、Zorn 和 McKinley 合著的 Reconsidering Custom Memory Allocation 再次提及了定制分配的主题,看是否真正值得为其费心。 关于垃圾收集的文章 Paul R. Wilson 撰写的 Uniprocessor Garbage Collection Techniques 给出了垃圾收集的一个基本概述。 Benjamin Zorn 撰写的 The Measured Cost of Garbage Collection 给出了关于垃圾收集和性能的硬数据(hard data)。 Hans-Juergen Boehm 撰写的 Memory Allocation Myths and Half-Truths 给出了关于垃圾收集的神话(myths)。 Hans-Juergen Boehm 撰写的 Space Efficient Conservative Garbage Collection 是一篇描述他的用于 C/C++ 的垃圾收集器的文章。 Web 上的通用参考资料 内存管理参考 中有很多关于内存管理参考资料和技术文章的链接。 关于内存管理和内存层级的 OOPS Group Papers 是非常好的一组关于此主题的技术文章。 C++ 中的内存管理讨论的是为 C++ 编写定制的分配程序。 Programming Alternatives: Memory Management 讨论了程序员进行内存管理时的一些选择。 垃圾收集 FAQ 讨论了关于垃圾收集您需要了解的所有内容。 Richard Jones 的 Garbage Collection Bibliography 有指向任何您想要的关于垃圾收集的文章的链接。 书籍 Michael Daconta 撰写的 C++ Pointers and Dynamic Memory Management 介绍了关于内存管理的很多技术。 Frantisek Franek 撰写的 Memory as a Programming Concept in C and C++ 讨论了有效使用内存的技术与工具,并给出了在计算机编程中应当引起注意的内存相关错误的角色。 Richard Jones 和 Rafael Lins 合著的 Garbage Collection: Algorithms for Automatic Dynamic Memory Management 描述了当前使用的最常见的垃圾收集算法。 在 Donald Knuth 撰写的 The Art of Computer Programming 第 1 卷 Fundamental Algorithms 的第 2.5 节“Dynamic Storage Allocation”中,描述了实现基本的分配程序的一些技术。 在 Donald Knuth 撰写的 The Art of Computer Programming 第 1 卷 Fundamental Algorithms 的第 2.3.5 节“Lists and Garbage Collection”中,讨论了用于列表的垃圾收集算法。 Andrei Alexandrescu 撰写的 Modern C++ Design 第 4 章“Small Object Allocation”描述了一个比 C++ 标准分配程序效率高得多的一个高速小对象分配程序。 Andrei Alexandrescu 撰写的 Modern C++ Design 第 7 章“Smart Pointers”描述了在 C++ 中智能指针的实现。 Jonathan 撰写的 Programming from the Ground Up 第 8 章“Intermediate Memory Topics”中有本文使用的简单分配程序的一个汇编语言版本。 来自 developerWorks 自我管理数据缓冲区内存 (developerWorks,2004 年 1 月)略述了一个用于管理内存的自管理的抽象数据缓存器的伪 C (pseudo-C)实现。 A framework for the user defined malloc replacement feature (developerWorks,2002 年 2 月)展示了如何利用 AIX 中的一个工具,使用自己设计的内存子系统取代原有的内存子系统。 掌握 Linux 调试技术 (developerWorks,2002 年 8 月)描述了可以使用调试方法的 4 种不同情形:段错误、内存溢出、内存泄漏和挂起。 在 处理 Java 程序中的内存漏洞 (developerWorks,2001 年 2 月)中,了解导致 Java 内存泄漏的原因,以及何时需要考虑它们。 在 developerWorks Linux 专区中,可以找到更多为 Linux 开发人员准备的参考资料。 从 developerWorks 的 Speed-start your Linux app 专区中,可以下载运行于 Linux 之上的 IBM 中间件产品的免费测试版本,其中包括 WebSphere® Studio Application Developer、WebSphere Application Server、DB2® Universal Database、Tivoli® Access Manager 和 Tivoli Directory Server,查找 how-to 文章和技术支持。 通过参与 developerWorks blogs 加入到 developerWorks 社区。 可以在 Developer Bookstore Linux 专栏中定购 打折出售的 Linux 书籍。 关于作者 Jonathan Bartlett 是 Programming from the Ground Up 一书的作者,这本书介绍的是 Linux 汇编语言编程。Jonathan Bartlett 是 New Media Worx 的总开发师,负责为客户开发 Web、视频、kiosk 和桌面应用程序。您可以通过 [email protected] 与 Jonathan 联系。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

次元工程师!

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值