杂记随感

Jonathan Bartlett （johnnyb@eskimo.com）
技术总监, New Media Worx
2004 年 11 月

本文将对 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 将是初始化内存分配程序的函数。它要完成以下三件事：将分配程序标识为已经初始化，找到系统中最后一个有效内存地址，然后建立起指向我们管理的内存的指针。这三个变量都是全局变量：

int has_initialized = 0;

void *managed_memory_start;

void *last_valid_address;

如前所述，被映射的内存的边界（最后一个有效地址）常被称为系统中断点或者当前中断点。在很多 UNIX® 系统中，为了指出当前系统中断点，必须使用 sbrk(0) 函数。sbrk 根据参数中给出的字节数移动当前系统中断点，然后返回新的系统中断点。使用参数 0 只是返回当前中断点。这里是我们的 malloc 初始化代码，它将找到当前中断点并初始化我们的变量：

/* Include the sbrk function */

#include <unistd.h>

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 返回的每块内存的起始处首先要有这个结构：

struct mem_control_block {

	int is_available;

	int size;

};

现在，您可能会认为当程序调用 malloc 时这会引发问题 —— 它们如何知道这个结构？答案是它们不必知道；在返回指针之前，我们会将其移动到这个结构之后，把它隐藏起来。这使得返回的指针指向没有用于任何其他用途的内存。那样，从调用程序的角度来看，它们所得到的全部是空闲的、开放的内存。然后，当通过 free() 将该指针传递回来时，我们只需要倒退几个内存字节就可以再次找到这个结构。

在讨论分配内存之前，我们将先讨论释放，因为它更简单。为了释放内存，我们必须要做的惟一一件事情就是，获得我们给出的指针，回退 sizeof(struct mem_control_block) 个字节，并将其标记为可用的。这里是对应的代码：

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;
}

如您所见，在这个分配程序中，内存的释放使用了一个非常简单的机制，在固定时间内完成内存释放。分配内存稍微困难一些。以下是该算法的略述：

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

我们主要使用连接的指针遍历内存来寻找开放的内存块。这里是代码：

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() 才是最主要的函数）：

gcc -shared -fpic malloc.c -o malloc.so

该程序将生成一个名为 malloc.so 的文件，它是一个包含有我们的代码的共享库。

在 UNIX 系统中，现在您可以用您的分配程序来取代系统的 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。结束这个动作之后，它还会检查计数是否已经减到零。如果是，那么它将释放内存。

这样做的好处是，您不必追踪程序中某个给定的数据结构可能会遵循的每一条路径。每次对其局部的引用，都将导致计数的适当增加或减少。这样可以防止在使用数据结构时释放该结构。不过，当您使用某个采用引用计数的数据结构时，您必须记得运行引用计数函数。另外，内置函数和第三方的库不会知道或者可以使用您的引用计数机制。引用计数也难以处理发生循环引用的数据结构。

要实现引用计数，您只需要两个函数 —— 一个增加引用计数，一个减少引用计数并当计数减少到零时释放内存。

一个示例引用计数函数集可能看起来如下所示：

/* 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 第一个指针。

以下是一个使用引用计数的生动的代码示例：

/* 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：

#include <obstack.h>

#include <stdlib.h>

/* 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. 内存分配策略的对比

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  

• 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 实现。
  
  
• ElectricFence Malloc Debugger 是一个调试程序中内存问题的 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 系统。
  

• 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++ 的垃圾收集器的文章。
  

• 内存管理参考 中有很多关于内存管理参考资料和技术文章的链接。
  
  
• 关于内存管理和内存层级的 OOPS Group Papers 是非常好的一组关于此主题的技术文章。
  
  
• C++ 中的内存管理讨论的是为 C++ 编写定制的分配程序。
  
  
• Programming Alternatives: Memory Management 讨论了程序员进行内存管理时的一些选择。
  
  
• 垃圾收集 FAQ 讨论了关于垃圾收集您需要了解的所有内容。
  
  
• Richard Jones 的 Garbage Collection Bibliography 有指向任何您想要的关于垃圾收集的文章的链接。
  
  
• 用于动态存储分配和内存管理的调试工具 很好地列出了用于在程序中寻找内存问题的 malloc 实现。
  

• 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，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 书籍。
  

先说一说编译器吧，主要是GNU的和arm公司的这两种编译器。
arm公司出的开发环境ADS用的就是他们自己的编译器。而GNU
的编译器开源的，很容易下载到的，支持很多架构的处理器。
所以学会了GUN的一套开发流程，就可以适应各种架构的系统
的开发了。
以前是习惯于在windows下面写代码，然后只要点一个build按
钮就一切搞定了，很方便；而在linux下面，用GNU开发，尤其
是需要交叉编译的时候，基本上什么东西都需要手工编写，如
Makefile，在编写操作系统无关的程序是还要自己编写连接脚
本。另外在调试程序时用的还是那种命令行方式的。到目前为
止似乎没有过linux下的集成开发环境的。我想以后应该也不会
有吧。应为这样虽然很麻烦，但是确实可以为我们开发提供最
大的灵活性。
不过网上面关于这方面的中文资料确实不多；这两天想找一些
关于GNU的arm汇编的语法的资料文档都找不到。郁闷ing...

再来说说操作系统，我觉得现在最有潜力的嵌入式操作系统大
概就是uClinux,它和linux一样也时开源的，现在有很多人都
在致力与把uClinux移植到不同的CPU平台上，这是一项很有难
度的任务，我们得到的是已经移植好的uClinux(for44b0)，所
以省去了很多的工作。不过如果能学会移植的话那就更好了。

然后不能不提的就是bootloader了，这个东西也是个硬件相关
的。不同的平台所使用的bootloader是不一样的。我们现在也
是暂时用别人的，以后有机会还是要仔细研究一下，最好能自
己写一个。bootloader这个东西作用很大的，他是系统上电后
运行的第一个程序，它一方面用来自动加载操作系统；另一方
面也可以用来从上位机手动下载和烧写程序到内存和flash。

bootloader是驻留在flash和rom中的，那么它又是怎么被下载
进去的呢？原来是通过jtag线下载的。好，再来说说这个jtag。
根据IEEE1149标准，上位机可以通过jtag接口设置芯片管脚的
电平，进而操作其内部的寄存器，也可以让处理器运行指令，
这样我们就可以把上位机的东西烧写到目标板的flash中了。
关于这个上位机的程序也是硬件相关的，应为不同的处理器扫
描链的定义是不一样的，并且对目标板的flash操作也是有区别
的。前一段时间也大概看了一下别人的4510的flash烧写程序，
自己也没有去写。

嵌入式系统是有很多外设的，所以不能不提的是他们的驱动程序。
开发驱动程序也分操作系统相关和无关两种，凭感觉后一种应该
要简单一点吧。没写过，只是猜测。前一段时间也是一直在看
linux(x86平台)下的驱动开发，自己也是照着书上的例子写了一
个很简单的字符设备驱动，也算有点成就感了，:-) 但是以后要
学的的东西真的是很多，在写操作系统相关的驱动时肯定是要去
看操作系统的，研究操作系统不用说肯定是一件很难的事的。不
过一旦深入下去提高也是非常快的。

最后在闲话几句我现在还不了解不多的文件系统和图形界面，我
想这些都是不得不面对的东西。看驱动是接触到一些和驱动相关
的文件系统的东西，很肤浅的。到时候如果真的开发自己的应用
程序是肯定要仔细研究的，图形界面也差不多吧。

对了，还有硬件，布板也是一项很繁琐很有难度的任务，我的一
个师兄在做，不过这个应该不用担心吧，我们实验室这个是强项，
真正要用在学也是很快的。

这么长时间，虽然没有真正深入学到什么东西，但是总算把很多
概念上，流程上的东西搞清楚了一点，以后目标应该是比较明确
的了。
我们实验室搞嵌入式系统也是刚刚开始，现在全是靠自己在摸索。
网上的论坛虽然能够帮上忙，但是效率确实很低；而网上文档资
料也很多，但是真正相关的有用的也很难找到。周围又没有什么
可以问的，也没有什么现成的资料参考，那就靠自己找，靠自己
总结。也没什么更好的办法了。也许以后工作中也是这样呢？

-----------------------------------------------------------------------------

吃牛排，减肥，打好球-这样的异想天开能成真吗？
 

    网球选手能坚持低碳水化合物的食谱并保持足够的精力打好比赛吗？ 答案是肯定的，这里有详细做法。

    营养学领域去年经历了一场翻天覆地的变革。实际上，正确饮食的口号可能已改成《帝国反击战》中由达对卢克说的那句话"你必须颠覆你所学的一切" 多年以来，我们一直奉行高碳水化合物低脂肪的食谱是减肥和健康之道的信条。 这种说法在1992年美国农业部发表的饮食指导金字塔时被正式确立，金子塔建议大量摄入面包，通心粉，稻米，麦片含有的碳水化合物，少量摄取蛋白质和脂肪。现在看来，这个金字塔的理论基础并不那么稳固。

    "这理论有非常大的漏洞"哈佛公众健康学院营养学系教授沃特.维莱特博士说。"理论中说所有的脂肪都有害，所有的合成碳水化合物都有益，所有蛋白质来源都提供同样的营养，而奶制品需要大量摄入。上述没有一项是准确的"

    事实上，最近的资料显示了另外一种理论假设：摄入太多碳水化合物会使我们超重，而如果我们食用少量碳水化合物，多些蛋白质甚至脂肪会使我们减轻体重。

    罗伯特.阿金斯博士1972年在他的《饮食革命》中提出的这一理论被医学界权威打为异端邪说。但30多年后，当整个美国都在肥胖蔓延的边缘，阿金斯的思想正在被更多人接受。去年，新英格兰医学杂志报道了遵循高蛋白、高脂肪、低碳水化合物的食谱的人在六个月内比遵照标准低脂肪食谱的人多减重达两倍之多。

    现在美国正经历低碳水化合物风暴。超市辟出单独区域作为阿金斯推荐的食品专区。快餐店也在他们的食谱上加上了低碳水化合物的选择。

    当计算碳水化合物成为时尚时，对于网球选手而言，这是否是明智之举呢？碳水化合物长期以来一直都是运动员首选的能量之源。当你减少了碳水化合物摄入，你还能在场上发挥你的最佳水平吗？

    一句话，当然可以。

    娱乐性网球并不能消耗太多卡路里，所以如果你想保持体重并在场上提高速度，那么低碳水化合物的食谱是个好的选择。纽约的营养学家斯戴芬妮.舒瓦茨这样说。

    "低碳水化合物、高脂肪的饮食能提高你的耐力，并给你更多的能量。"杰夫.沃勒克博士说。沃勒克博士是康涅狄格大学人体机能实验室的助理教授，主要研究饮食对运动员的影响。他说"低碳水化合物能驱动身体，有利于新陈代谢，并能使脂肪更多的作为能量燃烧。

    那么这是说网球运动员都应该成为阿金斯的拥趸者吗？并不尽然。

    大多数营养学家相信非职业的娱乐性质运动需要比阿金斯的规定更多的碳水化合物。职业选手通常更年轻，他们的运动频率也会为他们消耗相当多通心粉样的食物能量。相反，那些业余选手-"周末勇士"们，则最好遵循适度的低碳水化合物饮食体系。每一个饮食体系都有它的规则，下面是一些为向新营养世界过渡的网球选手们提供的准则。

    避免精细加工的碳水化合物

    遇到碳水化合物的问题，要区分选则，不要简单排斥。莱斯莉.伯奇博士说。伯奇博士是匹兹堡大学体育医学研究中心，体育营养学项目的负责人，伯奇博士说很多运动员都指望碳水化合物帮助他们更轻更快。但她警告说"你的身体确实需要碳水化合物，但只需要合适的碳水化合物"。专家们一致同意应该尽量少吃来自白米，面包，通心粉，比萨饼等富含精细碳水化合物的食物，也应少吃简单碳水化合物如糖类。精细碳水化合物会导致血糖快速升高。然后你的身体会产生胰岛素来促使血糖进入肌肉产生能量。沃勒克博士说："如果你的血糖会超常降低，会导致你在进食后一两个小时后感觉疲劳，然后你会吃更多碳水化合物来获取能量，如此陷入恶性循环。"

    要吃高纤维碳水化合物

    高纤维碳水化合物可以作为很好的能量来源而不刺激你的血糖浓度。为什么？纤维的分子可以分解产生糖，富含纤维的食物包括全麦麦片、紫米，蔬菜，坚果，和种子。"作为每餐的一部分，吃些蔬菜-它们是碳水化合物和水的来源。伯奇博士说。"四分之一的食物应该含有其他碳水化合物，网球大小的一碗紫米饭，或全麦面包，不用像炮弹一样大。这些量的碳水化合物可以给你足够的能量，而不是太多卡路里。

    比赛前吃些适当的小吃

网球选手通常在比赛前抓个松糕或百吉饼吃。这可不明智，因为这些零食都有很高的升糖指数。选择一碗燕麦片，脱脂奶酪，坚果，浆果，或涂了花生酱的全麦面包，这些食物会给你能量而不会在一个小时后让你累垮。

    带合适的零食到赛场

"坚果，特别是盐味坚果，对网球选手是最理想的零食，"伯奇博士说，"你会得到一些碳水化合物，盐会帮助因排汗而损失的钠。"

    把水果留在果盘里吧

你大概在比赛前或比赛中吃过香蕉或其他水果来保持体力吧，但那不是最佳的能量选择。水果中含有高果糖--一种浓缩的天然糖分，它会使你的血糖升高。如果你运动时喝果汁，那么你完全是自寻灾难。"果汁含有大量糖分"耶鲁大学纽黑文医院的莉萨.科梅尔博士说。"为了让血液吸收这些碳水化合物，水分被推入肠内帮助消化，而这可能导致腹痛，晕眩，腹泻。"你可以考虑喝些运动饮料，但也要适量。"运动饮料没用高糖"科梅尔博士指出8盎司的运动饮料通常只含14克碳水化合物，而同量的果汁中则含有30克。

    比赛后要吃的不同

刚刚运动后，最好吃些升糖指数适中或较高的食物。"这有助于体内的能量补给而又不刺激血糖浓度，因为血液中的葡萄糖会被肌肉快速吸收。"沃勒克博士说，进食的最佳时机在运动后的两小时内。他还指出如果运动员不及时补充肝糖（体内葡萄糖的储藏形式），会在接下来的24小时内感到疲劳乏力，妨碍体力恢复。那什么是明智的赛后餐呢？全麦面包火鸡三明志，土豆片，和水果是个不错的组合。如果你还想纵容一下自己，那么来杯可乐，吃冰激凌的理想时刻也是在赛后。

    大量喝水

    刚开始遵循低碳水化合物的食谱时，你减轻的体重大多是水分。这期间你应该避免利尿的咖啡因，并尽量多喝水。科梅尔博士给出这样的建议"在打网球前两小时喝14到22盎司（约400-600毫升）的水，运动时每20分钟再喝6到12盎司（约170-340毫升），另外赛后还有20盎司（约570毫升）。刚尝试低碳水化合物食谱时也会有腿部乏力的状况，"那可能是肌肉中肝糖储备不够或脱水造成的，"伯奇博士说，"应该多喝水并考虑赛前加些碳水化合物的零食。"

    吃低蛋白食品

    大多数营养师会建议吃鸡和鱼类等低蛋白含量的食品。尤其是鱼类，因为像鲑鱼，大比目鱼，金枪鱼都富含具有抗炎效果的不饱和脂肪酸。而奶制品是另一种蛋白质（和钙）的很好来源。那脂肪呢？大多数人认为所有脂肪都对人有害，其实不然。像橄榄和坚果油这样的不饱和脂肪，在适量情况下，是对人有益的，因为它可以促进人体的高密度脂蛋白（有益胆固醇),而降低低密度脂蛋白（有害胆固醇)" 。甚至在肉类中的饱和脂肪，最坏情况，也是好坏掺半，因为它既升高人体的有益胆固醇也升高有害胆固醇。

    下面是一些应该避免的高碳水化合物的食物，取而代之的应该是。。。

    避免...

    带面包的汉堡

    常规可乐

    薯片或饼干

    桔汁

    牛奶

    早餐麦片

    炸鸡

    通心粉

    土豆

 
    替换成

    无面包汉堡

    水或苏打水

    坚果，全麦饼抹花生酱

    草莓或其他浆果

    脱脂奶酪、奶酪

    鳄梨酱

    鸡蛋

    烤鸡

    绿色沙拉配火腿、奶酪、煮蛋、沙拉酱

    西兰花、菠菜、芦笋

    计算碳水化合物

    多少克的碳水化合物是正好让你减轻脂肪而又在场上保持足够的能量呢？每个人的需要都不同，你应当让营养师帮助量身定制你的食谱。多数专家建议运动量大的人至少40%的日常卡路里应该从碳水化合物中获得。

    放轻松

    最后：如果你想走低碳水化合物之路，最好不宜速成。记住，早期你的身体会失去很多水分，这绝不会很快适应。因为新陈代谢和来自身体的压力，你不可以在初尝此道时剧烈运动。应该在开始低碳水化合物食谱后的两个星期后再进行全面训练或比赛。

转自 http://www.tennis.com.cn　2004-5-28 13:56:49

------------------------------------------

如果身体不能储存足够能量，你就无法在比赛中正常发挥，因此要摄取适量的糖、蛋白质和脂肪来为身体提供能量。一位优秀的运动员必须接受高强度的体能和技术的训练，来保持竞技状态，同时还要预防在训练或比赛中的运动伤害。营养与体能和运动伤害之间有着密切的关系，因此保持饮食结构的均衡是运动员必须遵守的原则，偏食或营养不良将会影响运动员的体能表现，甚至造成运动伤害。某些球员经常这样做：为了降低体重来提高速度和耐力，他们就尽量不吃诸如面包、谷物、面食以及土豆等含糖较高但可能提高体重的食品，而是多吃肉类、鸡蛋以及其他富含蛋白质的食物。

    起初，他的体重确实会下降。但据宾夕法尼亚大学运动营养学研究室主任克里斯丁·克拉克博士說："无论是谁，如果总是摄入如此多的蛋白质，一定会导致体能下降，最终他将无法适应比赛。"

    任何级别的网球选手都可能遇到这样的问题。美国网协运动科学委员会委员佩奇·拉沃博士指出："任何一个顶尖选手都可能陷入高蛋白饮食的误区，而这种错误倾向将会对他们的竞技水平产生深远的影响。"

    营养是健康的根本，食物是营养的来源。我们身体需要食物中的营养素来维持生命，这些营养素包括糖类、蛋白质、脂肪、维生素和矿物质。糖类和脂肪产生的热量是日常活动的体力来源，蛋白质是人体生长发育和新陈代谢所必需的原料，维生素和矿物质则能起到调节生理的作用。

    从营养学的角度讲，食物一般分六大类，即五谷根茎类（主食类）、奶类、蛋豆鱼肉类、蔬菜类、水果类和油脂类。一般人可以根据自己的身体状况和活动量，每天吃主食3-6碗，奶1-2杯，蛋豆鱼肉类150-200克，蔬菜类180克，水果2个以及油脂2-3匙。

    数十年来，运动营养学家时常会推荐富含糖类，并搭配了适量的蛋白质和脂肪的饮食结构。乔治亚医学院的迈克尔·伯格伦博士说："我们的研究结果是，经常打网球或参加体育活动的人，应该采用这样的饮食搭配，而这是帮助你在运动中有出色表现的关键。"

    世界顶尖的双打选手利萨·雷蒙德也说："在饮食方面我从不含糊，为了在比赛中达到最佳状态，我就要摄入适量的糖类及蛋白质。我知道每天该吃什么、不该吃什么，因为这真的会影响到我的比赛成绩。"

    但摄入多少糖类和蛋白质才合适呢？确定你摄入的营养搭配是否合理的第一步就是确定你每天应该摄入多少卡路里。通常情况下，正常人应该摄入的卡路里与体重的比例是33-55卡/千克，也就是说一个体重是68千克的人每天应该摄入的热量是2,244到3,740卡路里之间。类似于雷蒙德这样的职业球员应摄入的热量为这个数值的上限；而偶尔打球的业余球员每天热量摄入量应该在此数值的下限。只要算出你每天应该摄入的热量值，就可以按照下面的指导拟定食谱了：

    糖类

    主要作用：提供能量。

    工作原理：很简单。如果不能在赛前摄入足够糖类，你甚至不能坚持打完一盘比赛。乔治亚大学健康与人类科学学院副院长，同时也是《运动营养学》一书作者的丹·博纳多特博士说："糖份是制约你发挥的一个重要因素，如果糖在你的食谱里不能占到足够高的比例，你就不可能连续做出高强度的动作。"

    糖类是人类最直接也是最主要的热量来源，更是脑部及神经细胞的能量来源，运动员要增加耐力，就必须吃足够的主食、蔬菜及水果，以获得充足的糖类。这些食物一旦被消化之后，就会迅速转化为肝糖，并为肌肉组织提供所需的能量。糖类被吸收后，血糖浓度会增加，如果血糖浓度过低（小于50mg/100c.c.），运动员的神经系统和肌肉组织就会受到影响，进而出现头重脚轻、疲倦及头晕等症状。此外，多余的血糖会转变成肝糖，贮存于肝脏的肌肉中，而肌肉中肝糖含量的多少将影响到运动员在体能方面的表现，换句话说，体内肝糖含量越高，对于耐力性运动就越有帮助。运动营养学家苏珊·坎德拉特介绍："把你的肌肉想象成一块海绵，你希望它尽可能的饱满。糖分能够迅速被肌肉吸收，所以它们是能量的最佳来源。但摄入过多糖分也不好，正是我们对多摄入糖类的畏惧导致了高蛋白食品的风行。因此，可以通过丰富饮食结构来摄取糖类，可以从诸如全麦面包、谷类、水果和蔬菜中摄取糖类；而尽量少吃含糖量过高的食物，如饼干、蛋糕以及软饮料和精面面包等。"

    摄取公式：每天摄入糖量与体重的比例可以控制在6.6-8.8克/千克。换句话说，你每天摄入的热量的50％-60％应该来自糖类。

    最佳来源：全麦食物、蔬菜及水果。

    蛋白質

    主要作用：建造并恢复肌肉组织，制造荷尔蒙和生化酶。

    工作原理：蛋白质是维持人体生长发育、构成及修补细胞、组织的重要原料，它也是形成荷尔蒙及抗体的成分。许多教练及选手都认为摄取较多的蛋白质有利于提高运动员的成绩，因为肌肉是由蛋白质构成，摄取较多的蛋白质可以增加肌肉的力量。但并不是越多摄入蛋白质就意味着越能够长出更多的肌肉。坎德拉特说："人们认为高蛋白的饮食可以直接被肌肉组织吸收，这样的想法过于简单了。如果摄入过多的蛋白质和热量，它们就会变成脂肪。"

    蛋白质摄入过量还存在一些更严重的问题。由于蛋白质在代谢过程中会产生含氮废物，需要由肾脏排泄掉。如果每日摄取过量的蛋白质，则会增加肾脏及肝脏的负荷。此外，为了排泄掉这些含氮的废物，尿液及水分的排泄也必须增加，而体内诸如如钾、镁、钙等矿物质也会随之流失。故摄取过多的蛋白质会造成脱水及矿物质的流失，进而影响运动员的表现，WTA的首席医疗顾问卡罗尔·奥蒂斯说："过度摄入的蛋白质并不会被身体贮存起来，而且在分解的过程中，它们可能增加肾脏的负担，最终导致脱水。"；但如果蛋白质摄取不足，则体内的蛋白质会被分解，甚至导致贫血，同样会大大影响运动员的体能。

    摄取公式：蛋白质的摄入量需依个人运动量而定。通常建议每天蛋白质摄入量与体重的比例为1.1-2.2克/公斤；换句话说，就是占每日热量摄入量的15％-20％。

    最佳来源：低脂肪食品，诸如瘦肉、鸡肉、鱼肉、谷类、坚果以及鸡蛋。

    脂肪

    主要作用：提高对几种主要维生素的吸收，提供热量和必须脂肪酸，并可使食物更可口。

    工作原理：不要进入"谈脂肪色变"的误区，因为它不但可以使你在进食后感觉更饱，而且能够在运动中持续为你提供能量。博格伦博士说："在打网球的过程中会有很多脂肪被消耗掉，脂肪有利于保持较好的体力。"

    脂肪摄入量过少会破坏免疫系统；摄入过多又会降低运动员的体力和耐力。而且并不是所有的脂肪都是有益的。过稠的脂肪，如肉类、禽肉、全脂乳制品、以及椰子油和棕榈油中富含的脂肪，长期以来都被认为与心脏病和某些癌症有关。因此，可以选择食用含"复不饱合脂肪"的食物，如谷类、瓜子、大豆及鲑鱼和金枪鱼等鱼类；更好的选择是食用含"单不饱和脂肪"的食物，如橄榄油、芝麻等。

    进食公式：尽量把脂肪的摄入量保持在每天热量摄取的20％-30％。

    最佳来源：橄榄油、金枪鱼、鲑鱼、亚麻籽。

    维生素

    主要作用：维持人体健康与正常发育，调节身体的新陈代谢

    工作原理：绝大部分的维生素不能在体内合成，因此就需要从食物中摄取。以下介绍几种于运动关系最密切的维生素。

    （一）维生素B：维生素B对运动员的体能和成绩表现的影响可以分为两方面，一方面与热量代谢有关，这些维生素包括B1、B2、泛酸等。由于运动员在训练和比赛时，需要消耗较多的热量，因此要补充较多的维生素B1、B2。富含维生素B1的食物包括：米糠、动物肝脏、瘦肉、酵母、豆类和蛋黄等。富含维生素B2的食物有：酵母、内脏类、牛奶、蛋类、花生和豆类等。另一方面，维生素B与形成红血球有关，如：维生素B6、B12和叶酸。维生素B6缺乏会减少血红素的形成，而缺乏维生素B12和叶酸会导致恶性贫血。贫血会降低运动员体内氧气的输送，进而影响其体力和成绩。因此，要摄入足量的维生素B6、B12和叶酸。
 
    （二）维生素C：是细胞间质的主要构成物质，使细胞保持良好状况，加速伤口愈合，并增加对疾病的抵抗力。运动员缺乏维生素C，可能会导致肌肉裂伤或韧带裂伤等运动伤害；因为维生素C是强华血管、肌肉、韧带和肌腱的重要营养素。此外，维生素C还可以帮助铁质的吸收。女性运动员缺乏铁时，也应该多补充维生素C，可酌量增加摄取。富含维生素C的食物有：深绿及黄红色的蔬菜和水果，如青椒、蕃石榴、柑橘类、蕃茄、柠檬等。

    特别提示：为求合理的饮食结构，可以尝试鱼肉、粗粮、蔬菜、水果沙拉这样的組合；比赛中可以用全麦的点心、水果、酸奶和柳橙汁为你的比赛充电。

嵌入式系统 Boot Loader 技术内幕

詹荣开 (zhanrk@sohu.com)
2003 年 12 月

本文详细地介绍了基于嵌入式系统中的 OS 启动加载程序 ―― Boot Loader 的概念、软件设计的主要任务以及结构框架等内容.

1. 引言
在专用的嵌入式板子运行 GNU/Linux 系统已经变得越来越流行。一个嵌入式 Linux 系统从软件的角度看通常可以分为四个层次：

1. 引导加载程序。包括固化在固件(firmware)中的 boot 代码(可选)，和 Boot Loader 两大部分。

2. Linux 内核。特定于嵌入式板子的定制内核以及内核的启动参数。

3. 文件系统。包括根文件系统和建立于 Flash 内存设备之上文件系统。通常用 ram disk 来作为 root fs。

4. 用户应用程序。特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式 GUI 有：MicroWindows 和 MiniGUI 懂。

引导加载程序是系统加电后运行的第一段软件代码。回忆一下 PC 的体系结构我们可以知道，PC 机中的引导加载程序由 BIOS(其本质就是一段固件程序)和位于硬盘 MBR 中的 OS Boot Loader（比如，LILO 和 GRUB 等）一起组成。BIOS 在完成硬件检测和资源分配后，将硬盘 MBR 中的 Boot Loader 读到系统的 RAM 中，然后将控制权交给 OS Boot Loader。Boot Loader 的主要运行任务就是将内核映象从硬盘上读到 RAM 中，然后跳转到内核的入口点去运行，也即开始启动操作系统。

而在嵌入式系统中，通常并没有像 BIOS 那样的固件程序（注，有的嵌入式 CPU 也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由 Boot Loader 来完成。比如在一个基于 ARM7TDMI core 的嵌入式系统中，系统在上电或复位时通常都从地址 0x00000000 处开始执行，而在这个地址处安排的通常就是系统的 Boot Loader 程序。

本文将从 Boot Loader 的概念、Boot Loader 的主要任务、Boot Loader 的框架结构以及 Boot Loader 的安装等四个方面来讨论嵌入式系统的 Boot Loader。

2. Boot Loader 的概念
简单地说，Boot Loader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。

通常，Boot Loader 是严重地依赖于硬件而实现的，特别是在嵌入式世界。因此，在嵌入式世界里建立一个通用的 Boot Loader 几乎是不可能的。尽管如此，我们仍然可以对 Boot Loader 归纳出一些通用的概念来，以指导用户特定的 Boot Loader 设计与实现。

1. Boot Loader 所支持的 CPU 和嵌入式板

每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot Loader 也支持多种体系结构的 CPU，比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。除了依赖于 CPU 的体系结构外，Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 而构建的，要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上，通常也都需要修改 Boot Loader 的源程序。

2. Boot Loader 的安装媒介（Installation Medium）

系统加电或复位后，所有的 CPU 通常都从某个由 CPU 制造商预先安排的地址上取指令。比如，基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000 取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设备(比如：ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU 将首先执行 Boot Loader 程序。

下图1就是一个同时装有 Boot Loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。

图1 固态存储设备的典型空间分配结构

3. 用来控制 Boot Loader 的设备或机制

主机和目标机之间一般通过串口建立连接，Boot Loader 软件在执行时通常会通过串口来进行 I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。

4. Boot Loader 的启动过程是单阶段（Single Stage）还是多阶段（Multi-Stage）

通常多阶段的 Boot Loader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1 和 stage 2 两部分。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面讨论。

5. Boot Loader 的操作模式 (Operation Mode)

大多数 Boot Loader 都包含两种不同的操作模式："启动加载"模式和"下载"模式，这种区别仅对于开发人员才有意义。但从最终用户的角度看，Boot Loader 的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。

启动加载（Boot loading）模式：这种模式也称为"自主"（Autonomous）模式。也即 Boot Loader 从目标机上的某个固态存储设备上将操作系统加载到 RAM 中运行，整个过程并没有用户的介入。这种模式是 Boot Loader 的正常工作模式，因此在嵌入式产品发布的时侯，Boot Loader 显然必须工作在这种模式下。

下载（Downloading）模式：在这种模式下，目标机上的 Boot Loader 将通过串口连接或网络连接等通信手段从主机（Host）下载文件，比如：下载内核映像和根文件系统映像等。从主机下载的文件通常首先被 Boot Loader 保存到目标机的 RAM 中，然后再被 Boot Loader 写到目标机上的FLASH 类固态存储设备中。Boot Loader 的这种模式通常在第一次安装内核与根文件系统时被使用；此外，以后的系统更新也会使用 Boot Loader 的这种工作模式。工作于这种模式下的 Boot Loader 通常都会向它的终端用户提供一个简单的命令行接口。

像 Blob 或 U-Boot 等这样功能强大的 Boot Loader 通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进行切换。比如，Blob 在启动时处于正常的启动加载模式，但是它会延时 10 秒等待终端用户按下任意键而将 blob 切换到下载模式。如果在 10 秒内没有用户按键，则 blob 继续启动 Linux 内核。

6. BootLoader 与主机之间进行文件传输所用的通信设备及协议

最常见的情况就是，目标机上的 Boot Loader 通过串口与主机之间进行文件传输，传输协议通常是 xmodem／ymodem／zmodem 协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。

此外，在论及这个话题时，主机方所用的软件也要考虑。比如，在通过以太网连接和 TFTP 协议来下载文件时，主机方必须有一个软件用来的提供 TFTP 服务。

在讨论了 BootLoader 的上述概念后，下面我们来具体看看 BootLoader 的应该完成哪些任务。

3. Boot Loader 的主要任务与典型结构框架
在继续本节的讨论之前，首先我们做一个假定，那就是：假定内核映像与根文件系统映像都被加载到 RAM 中运行。之所以提出这样一个假设前提是因为，在嵌入式系统中内核映像与根文件系统映像也可以直接在 ROM 或 Flash 这样的固态存储设备中直接运行。但这种做法无疑是以运行速度的牺牲为代价的。

从操作系统的角度看，Boot Loader 的总目标就是正确地调用内核来执行。

另外，由于 Boot Loader 的实现依赖于 CPU 的体系结构，因此大多数 Boot Loader 都分为 stage1 和 stage2 两大部分。依赖于 CPU 体系结构的代码，比如设备初始化代码等，通常都放在 stage1 中，而且通常都用汇编语言来实现，以达到短小精悍的目的。而 stage2 则通常用C语言来实现，这样可以实现给复杂的功能，而且代码会具有更好的可读性和可移植性。

Boot Loader 的 stage1 通常包括以下步骤(以执行的先后顺序)：

• 硬件设备初始化。
  
  
• 为加载 Boot Loader 的 stage2 准备 RAM 空间。
  
  
• 拷贝 Boot Loader 的 stage2 到 RAM 空间中。
  
  
• 设置好堆栈。
  
  
• 跳转到 stage2 的 C 入口点。
  
  

Boot Loader 的 stage2 通常包括以下步骤(以执行的先后顺序)：

• 初始化本阶段要使用到的硬件设备。
  
  
• 检测系统内存映射(memory map)。
  
  
• 将 kernel 映像和根文件系统映像从 flash 上读到 RAM 空间中。
  
  
• 为内核设置启动参数。
  
  
• 调用内核。

3.1 Boot Loader 的 stage1

3.1.1 基本的硬件初始化

这是 Boot Loader 一开始就执行的操作，其目的是为 stage2 的执行以及随后的 kernel 的执行准备好一些基本的硬件环境。它通常包括以下步骤（以执行的先后顺序）：

1． 屏蔽所有的中断。为中断提供服务通常是 OS 设备驱动程序的责任，因此在 Boot Loader 的执行全过程中可以不必响应任何中断。中断屏蔽可以通过写 CPU 的中断屏蔽寄存器或状态寄存器（比如 ARM 的 CPSR 寄存器）来完成。

2． 设置 CPU 的速度和时钟频率。

3． RAM 初始化。包括正确地设置系统的内存控制器的功能寄存器以及各内存库控制寄存器等。

4． 初始化 LED。典型地，通过 GPIO 来驱动 LED，其目的是表明系统的状态是 OK 还是 Error。如果板子上没有 LED，那么也可以通过初始化 UART 向串口打印 Boot Loader 的 Logo 字符信息来完成这一点。

5． 关闭 CPU 内部指令／数据 cache。

3.1.2 为加载 stage2 准备 RAM 空间

为了获得更快的执行速度，通常把 stage2 加载到 RAM 空间中来执行，因此必须为加载 Boot Loader 的 stage2 准备好一段可用的 RAM 空间范围。

由于 stage2 通常是 C 语言执行代码，因此在考虑空间大小时，除了 stage2 可执行映象的大小外，还必须把堆栈空间也考虑进来。此外，空间大小最好是 memory page 大小(通常是 4KB)的倍数。一般而言，1M 的 RAM 空间已经足够了。具体的地址范围可以任意安排，比如 blob 就将它的 stage2 可执行映像安排到从系统 RAM 起始地址 0xc0200000 开始的 1M 空间内执行。但是，将 stage2 安排到整个 RAM 空间的最顶 1MB(也即(RamEnd-1MB) - RamEnd)是一种值得推荐的方法。

为了后面的叙述方便，这里把所安排的 RAM 空间范围的大小记为：stage2_size(字节)，把起始地址和终止地址分别记为：stage2_start 和 stage2_end(这两个地址均以 4 字节边界对齐)。因此：

stage2_end＝stage2_start＋stage2_size

另外，还必须确保所安排的地址范围的的确确是可读写的 RAM 空间，因此，必须对你所安排的地址范围进行测试。具体的测试方法可以采用类似于 blob 的方法，也即：以 memory page 为被测试单位，测试每个 memory page 开始的两个字是否是可读写的。为了后面叙述的方便，我们记这个检测算法为：test_mempage，其具体步骤如下：

1． 先保存 memory page 一开始两个字的内容。

2． 向这两个字中写入任意的数字。比如：向第一个字写入 0x55，第 2 个字写入 0xaa。

3． 然后，立即将这两个字的内容读回。显然，我们读到的内容应该分别是 0x55 和 0xaa。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM 空间。

4． 再向这两个字中写入任意的数字。比如：向第一个字写入 0xaa，第 2 个字中写入 0x55。

5． 然后，立即将这两个字的内容立即读回。显然，我们读到的内容应该分别是 0xaa 和 0x55。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM 空间。

6． 恢复这两个字的原始内容。测试完毕。

为了得到一段干净的 RAM 空间范围，我们也可以将所安排的 RAM 空间范围进行清零操作。

3.1.3 拷贝 stage2 到 RAM 中

拷贝时要确定两点：(1) stage2 的可执行映象在固态存储设备的存放起始地址和终止地址；(2) RAM 空间的起始地址。

3.1.4 设置堆栈指针 sp

堆栈指针的设置是为了执行 C 语言代码作好准备。通常我们可以把 sp 的值设置为(stage2_end-4)，也即在 3.1.2 节所安排的那个 1MB 的 RAM 空间的最顶端(堆栈向下生长)。

此外，在设置堆栈指针 sp 之前，也可以关闭 led 灯，以提示用户我们准备跳转到 stage2。

经过上述这些执行步骤后，系统的物理内存布局应该如下图2所示。

3.1.5 跳转到 stage2 的 C 入口点

在上述一切都就绪后，就可以跳转到 Boot Loader 的 stage2 去执行了。比如，在 ARM 系统中，这可以通过修改 PC 寄存器为合适的地址来实现。

图2 bootloader 的 stage2 可执行映象刚被拷贝到 RAM 空间时的系统内存布局

3.2 Boot Loader 的 stage2

正如前面所说，stage2 的代码通常用 C 语言来实现，以便于实现更复杂的功能和取得更好的代码可读性和可移植性。但是与普通 C 语言应用程序不同的是，在编译和链接 boot loader 这样的程序时，我们不能使用 glibc 库中的任何支持函数。其原因是显而易见的。这就给我们带来一个问题，那就是从那里跳转进 main() 函数呢？直接把 main() 函数的起始地址作为整个 stage2 执行映像的入口点或许是最直接的想法。但是这样做有两个缺点：1)无法通过main() 函数传递函数参数；2)无法处理 main() 函数返回的情况。一种更为巧妙的方法是利用 trampoline(弹簧床)的概念。也即，用汇编语言写一段trampoline 小程序，并将这段 trampoline 小程序来作为 stage2 可执行映象的执行入口点。然后我们可以在 trampoline 汇编小程序中用 CPU 跳转指令跳入 main() 函数中去执行；而当 main() 函数返回时，CPU 执行路径显然再次回到我们的 trampoline 程序。简而言之，这种方法的思想就是：用这段 trampoline 小程序来作为 main() 函数的外部包裹(external wrapper)。

下面给出一个简单的 trampoline 程序示例(来自blob)：

.text

.globl _trampoline
_trampoline:
	bl	main
	/* if main ever returns we just call it again */
	b	_trampoline

可以看出，当 main() 函数返回后，我们又用一条跳转指令重新执行 trampoline 程序――当然也就重新执行 main() 函数，这也就是 trampoline(弹簧床)一词的意思所在。

3.2.1初始化本阶段要使用到的硬件设备

这通常包括：（1）初始化至少一个串口，以便和终端用户进行 I/O 输出信息；（2）初始化计时器等。

在初始化这些设备之前，也可以重新把 LED 灯点亮，以表明我们已经进入 main() 函数执行。

设备初始化完成后，可以输出一些打印信息，程序名字字符串、版本号等。

3.2.2 检测系统的内存映射（memory map）

所谓内存映射就是指在整个 4GB 物理地址空间中有哪些地址范围被分配用来寻址系统的 RAM 单元。比如，在 SA-1100 CPU 中，从 0xC000,0000 开始的 512M 地址空间被用作系统的 RAM 地址空间，而在 Samsung S3C44B0X CPU 中，从 0x0c00,0000 到 0x1000,0000 之间的 64M 地址空间被用作系统的 RAM 地址空间。虽然 CPU 通常预留出一大段足够的地址空间给系统 RAM，但是在搭建具体的嵌入式系统时却不一定会实现 CPU 预留的全部 RAM 地址空间。也就是说，具体的嵌入式系统往往只把 CPU 预留的全部 RAM 地址空间中的一部分映射到 RAM 单元上，而让剩下的那部分预留 RAM 地址空间处于未使用状态。由于上述这个事实，因此 Boot Loader 的 stage2 必须在它想干点什么 (比如，将存储在 flash 上的内核映像读到 RAM 空间中) 之前检测整个系统的内存映射情况，也即它必须知道 CPU 预留的全部 RAM 地址空间中的哪些被真正映射到 RAM 地址单元，哪些是处于 "unused" 状态的。

(1) 内存映射的描述

可以用如下数据结构来描述 RAM 地址空间中的一段连续(continuous)的地址范围：

typedef struct memory_area_struct {
	u32 start; /* the base address of the memory region */
	u32 size; /* the byte number of the memory region */
	int used;
} memory_area_t;

这段 RAM 地址空间中的连续地址范围可以处于两种状态之一：(1)used=1，则说明这段连续的地址范围已被实现，也即真正地被映射到 RAM 单元上。(2)used=0，则说明这段连续的地址范围并未被系统所实现，而是处于未使用状态。

基于上述 memory_area_t 数据结构，整个 CPU 预留的 RAM 地址空间可以用一个 memory_area_t 类型的数组来表示，如下所示：

memory_area_t memory_map[NUM_MEM_AREAS] = {
	[0 ... (NUM_MEM_AREAS - 1)] = {
		.start = 0,
		.size = 0,
		.used = 0
	},
};

(2) 内存映射的检测

下面我们给出一个可用来检测整个 RAM 地址空间内存映射情况的简单而有效的算法：

/* 数组初始化 */
for(i = 0; i < NUM_MEM_AREAS; i++)
	memory_map[i].used = 0;

/* first write a 0 to all memory locations */
for(addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE)
	* (u32 *)addr = 0;

for(i = 0, addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE) {
     /*
      * 检测从基地址 MEM_START+i*PAGE_SIZE 开始,大小为
* PAGE_SIZE 的地址空间是否是有效的RAM地址空间。
      */
     调用3.1.2节中的算法test_mempage()；
     if ( current memory page isnot a valid ram page) {
		/* no RAM here */
		if(memory_map[i].used )
			i++;
		continue;
	}
	
	/*
	 * 当前页已经是一个被映射到 RAM 的有效地址范围
	 * 但是还要看看当前页是否只是 4GB 地址空间中某个地址页的别名？
	 */
	if(* (u32 *)addr != 0) { /* alias? */
		/* 这个内存页是 4GB 地址空间中某个地址页的别名 */
		if ( memory_map[i].used )
			i++;
		continue;
	}
	
	/*
	 * 当前页已经是一个被映射到 RAM 的有效地址范围
	 * 而且它也不是 4GB 地址空间中某个地址页的别名。
	 */
	if (memory_map[i].used == 0) {
		memory_map[i].start = addr;
		memory_map[i].size = PAGE_SIZE;
		memory_map[i].used = 1;
	} else {
		memory_map[i].size += PAGE_SIZE;
	}
} /* end of for (...) */

在用上述算法检测完系统的内存映射情况后，Boot Loader 也可以将内存映射的详细信息打印到串口。

3.2.3 加载内核映像和根文件系统映像

(1) 规划内存占用的布局

这里包括两个方面：(1)内核映像所占用的内存范围；（2）根文件系统所占用的内存范围。在规划内存占用的布局时，主要考虑基地址和映像的大小两个方面。

对于内核映像，一般将其拷贝到从(MEM_START＋0x8000) 这个基地址开始的大约1MB大小的内存范围内(嵌入式 Linux 的内核一般都不操过 1MB)。为什么要把从 MEM_START 到 MEM_START＋0x8000 这段 32KB 大小的内存空出来呢？这是因为 Linux 内核要在这段内存中放置一些全局数据结构，如：启动参数和内核页表等信息。

而对于根文件系统映像，则一般将其拷贝到 MEM_START+0x0010,0000 开始的地方。如果用 Ramdisk 作为根文件系统映像，则其解压后的大小一般是1MB。

（2）从 Flash 上拷贝

由于像 ARM 这样的嵌入式 CPU 通常都是在统一的内存地址空间中寻址 Flash 等固态存储设备的，因此从 Flash 上读取数据与从 RAM 单元中读取数据并没有什么不同。用一个简单的循环就可以完成从 Flash 设备上拷贝映像的工作：

while(count) {
	*dest++ = *src++; /* they are all aligned with word boundary */
	count -= 4; /* byte number */
};

3.2.4 设置内核的启动参数

应该说，在将内核映像和根文件系统映像拷贝到 RAM 空间中后，就可以准备启动 Linux 内核了。但是在调用内核之前，应该作一步准备工作，即：设置 Linux 内核的启动参数。

Linux 2.4.x 以后的内核都期望以标记列表(tagged list)的形式来传递启动参数。启动参数标记列表以标记 ATAG_CORE 开始，以标记 ATAG_NONE 结束。每个标记由标识被传递参数的 tag_header 结构以及随后的参数值数据结构来组成。数据结构 tag 和 tag_header 定义在 Linux 内核源码的include/asm/setup.h 头文件中：

/* The list ends with an ATAG_NONE node. */
#define ATAG_NONE	0x00000000

struct tag_header {
	u32 size; /* 注意，这里size是字数为单位的 */
	u32 tag;
};
......
struct tag {
	struct tag_header hdr;
	union {
		struct tag_core		core;
		struct tag_mem32	mem;
		struct tag_videotext	videotext;
		struct tag_ramdisk	ramdisk;
		struct tag_initrd	initrd;
		struct tag_serialnr	serialnr;
		struct tag_revision	revision;
		struct tag_videolfb	videolfb;
		struct tag_cmdline	cmdline;

		/*
		 * Acorn specific
		 */
		struct tag_acorn	acorn;

		/*
		 * DC21285 specific
		 */
		struct tag_memclk	memclk;
	} u;
};

在嵌入式 Linux 系统中，通常需要由 Boot Loader 设置的常见启动参数有：ATAG_CORE、ATAG_MEM、ATAG_CMDLINE、ATAG_RAMDISK、ATAG_INITRD等。

比如，设置 ATAG_CORE 的代码如下：

params = (struct tag *)BOOT_PARAMS;

	params->hdr.tag = ATAG_CORE;
	params->hdr.size = tag_size(tag_core);

	params->u.core.flags = 0;
	params->u.core.pagesize = 0;
	params->u.core.rootdev = 0;

	params = tag_next(params);

其中，BOOT_PARAMS 表示内核启动参数在内存中的起始基地址，指针 params 是一个 struct tag 类型的指针。宏 tag_next() 将以指向当前标记的指针为参数，计算紧临当前标记的下一个标记的起始地址。注意，内核的根文件系统所在的设备ID就是在这里设置的。

下面是设置内存映射情况的示例代码：

for(i = 0; i < NUM_MEM_AREAS; i++) {
		if(memory_map[i].used) {
			params->hdr.tag = ATAG_MEM;
			params->hdr.size = tag_size(tag_mem32);

			params->u.mem.start = memory_map[i].start;
			params->u.mem.size = memory_map[i].size;
			
			params = tag_next(params);
		}
}

可以看出，在 memory_map［］数组中，每一个有效的内存段都对应一个 ATAG_MEM 参数标记。

Linux 内核在启动时可以以命令行参数的形式来接收信息，利用这一点我们可以向内核提供那些内核不能自己检测的硬件参数信息，或者重载(override)内核自己检测到的信息。比如，我们用这样一个命令行参数字符串"console=ttyS0,115200n8"来通知内核以 ttyS0 作为控制台，且串口采用 "115200bps、无奇偶校验、8位数据位"这样的设置。下面是一段设置调用内核命令行参数字符串的示例代码：

char *p;

	/* eat leading white space */
	for(p = commandline; *p == ' '; p++)
		;

	/* skip non-existent command lines so the kernel will still
    * use its default command line.
	 */
	if(*p == '\0')
		return;

	params->hdr.tag = ATAG_CMDLINE;
	params->hdr.size = (sizeof(struct tag_header) + strlen(p) + 1 + 4) >> 2;

	strcpy(params->u.cmdline.cmdline, p);

	params = tag_next(params);

请注意在上述代码中，设置 tag_header 的大小时，必须包括字符串的终止符'\0'，此外还要将字节数向上圆整4个字节，因为 tag_header 结构中的size 成员表示的是字数。

下面是设置 ATAG_INITRD 的示例代码，它告诉内核在 RAM 中的什么地方可以找到 initrd 映象(压缩格式)以及它的大小：

	params->hdr.tag = ATAG_INITRD2;
	params->hdr.size = tag_size(tag_initrd);
	
	params->u.initrd.start = RAMDISK_RAM_BASE;
	params->u.initrd.size = INITRD_LEN;
	
	params = tag_next(params);

下面是设置 ATAG_RAMDISK 的示例代码，它告诉内核解压后的 Ramdisk 有多大（单位是KB）：

params->hdr.tag = ATAG_RAMDISK;
params->hdr.size = tag_size(tag_ramdisk);
	
params->u.ramdisk.start = 0;
params->u.ramdisk.size = RAMDISK_SIZE; /* 请注意，单位是KB */
params->u.ramdisk.flags = 1; /* automatically load ramdisk */
	
params = tag_next(params);

最后，设置 ATAG_NONE 标记，结束整个启动参数列表：

static void setup_end_tag(void)
{
	params->hdr.tag = ATAG_NONE;
	params->hdr.size = 0;
}

3.2.5 调用内核

Boot Loader 调用 Linux 内核的方法是直接跳转到内核的第一条指令处，也即直接跳转到 MEM_START＋0x8000 地址处。在跳转时，下列条件要满足：

1． CPU 寄存器的设置：

• R0＝0；
  
  
• R1＝机器类型 ID；关于 Machine Type Number，可以参见 linux/arch/arm/tools/mach-types。
  
  
• R2＝启动参数标记列表在 RAM 中起始基地址；
  
  

2． CPU 模式：

• 必须禁止中断（IRQs和FIQs）；
  
  
• CPU 必须 SVC 模式；
  
  

3． Cache 和 MMU 的设置：

• MMU 必须关闭；
  
  
• 指令 Cache 可以打开也可以关闭；
  
  
• 数据 Cache 必须关闭；

如果用 C 语言，可以像下列示例代码这样来调用内核：

void (*theKernel)(int zero, int arch, u32 params_addr) = (void (*)(int, int, u32))KERNEL_RAM_BASE;
......
theKernel(0, ARCH_NUMBER, (u32) kernel_params_start);

注意，theKernel()函数调用应该永远不返回的。如果这个调用返回，则说明出错。

4. 关于串口终端
在 boot loader 程序的设计与实现中，没有什么能够比从串口终端正确地收到打印信息能更令人激动了。此外，向串口终端打印信息也是一个非常重要而又有效的调试手段。但是，我们经常会碰到串口终端显示乱码或根本没有显示的问题。造成这个问题主要有两种原因：(1) boot loader 对串口的初始化设置不正确。(2) 运行在 host 端的终端仿真程序对串口的设置不正确，这包括：波特率、奇偶校验、数据位和停止位等方面的设置。

此外，有时也会碰到这样的问题，那就是：在 boot loader 的运行过程中我们可以正确地向串口终端输出信息，但当 boot loader 启动内核后却无法看到内核的启动输出信息。对这一问题的原因可以从以下几个方面来考虑：

(1) 首先请确认你的内核在编译时配置了对串口终端的支持，并配置了正确的串口驱动程序。

(2) 你的 boot loader 对串口的初始化设置可能会和内核对串口的初始化设置不一致。此外，对于诸如 s3c44b0x 这样的 CPU，CPU 时钟频率的设置也会影响串口，因此如果 boot loader 和内核对其 CPU 时钟频率的设置不一致，也会使串口终端无法正确显示信息。

(3) 最后，还要确认 boot loader 所用的内核基地址必须和内核映像在编译时所用的运行基地址一致，尤其是对于 uClinux 而言。假设你的内核映像在编译时用的基地址是 0xc0008000，但你的 boot loader 却将它加载到 0xc0010000 处去执行，那么内核映像当然不能正确地执行了。

5. 结束语
Boot Loader 的设计与实现是一个非常复杂的过程。如果不能从串口收到那激动人心的"uncompressing linux.................. done, booting the kernel......"内核启动信息，恐怕谁也不能说："嗨，我的 boot loader 已经成功地转起来了！"。

Linux 内核配置系统浅析

汤凯 (tangk73@hotmail.com)

随着 Linux 操作系统的广泛应用，特别是 Linux 在嵌入式领域的发展，越来越多的人开始投身到 Linux 内核级的开发中。面对日益庞大的 Linux 内核源代码，开发者在完成自己的内核代码后，都将面临着同样的问题，即如何将源代码融入到 Linux 内核中，增加相应的 Linux 配置选项，并最终被编译进 Linux 内核。这就需要了解 Linux 的内核配置系统。

众所周知，Linux 内核是由分布在全球的 Linux 爱好者共同开发的，Linux 内核每天都面临着许多新的变化。但是，Linux 内核的组织并没有出现混乱的现象，反而显得非常的简洁，而且具有很好的扩展性，开发人员可以很方便的向 Linux 内核中增加新的内容。原因之一就是 Linux 采用了模块化的内核配置系统，从而保证了内核的扩展性。

本文首先分析了 Linux 内核中的配置系统结构，然后，解释了 Makefile 和配置文件的格式以及配置语句的含义，最后，通过一个简单的例子--TEST Driver，具体说明如何将自行开发的代码加入到 Linux 内核中。在下面的文章中，不可能解释所有的功能和命令，只对那些常用的进行解释，至于那些没有讨论到的，请读者参考后面的参考文献。

1． 配置系统的基本结构

Linux内核的配置系统由三个部分组成，分别是：

1. Makefile：分布在 Linux 内核源代码中的 Makefile，定义 Linux 内核的编译规则；
2. 配置文件（config.in）：给用户提供配置选择的功能；
3. 配置工具：包括配置命令解释器（对配置脚本中使用的配置命令进行解释）和配置用户界面（提供基于字符界面、基于 Ncurses 图形界面以及基于 Xwindows 图形界面的用户配置界面，各自对应于 Make config、Make menuconfig 和 make xconfig）。

这些配置工具都是使用脚本语言，如 Tcl/TK、Perl 编写的（也包含一些用 C 编写的代码）。本文并不是对配置系统本身进行分析，而是介绍如何使用配置系统。所以，除非是配置系统的维护者，一般的内核开发者无须了解它们的原理，只需要知道如何编写 Makefile 和配置文件就可以。所以，在本文中，我们只对 Makefile 和配置文件进行讨论。另外，凡是涉及到与具体 CPU 体系结构相关的内容，我们都以 ARM 为例，这样不仅可以将讨论的问题明确化，而且对内容本身不产生影响。

2． Makefile

2.1 Makefile 概述

Makefile 的作用是根据配置的情况，构造出需要编译的源文件列表，然后分别编译，并把目标代码链接到一起，最终形成 Linux 内核二进制文件。

由于 Linux 内核源代码是按照树形结构组织的，所以 Makefile 也被分布在目录树中。Linux 内核中的 Makefile 以及与 Makefile 直接相关的文件有：

1. Makefile：顶层 Makefile，是整个内核配置、编译的总体控制文件。
2. .config：内核配置文件，包含由用户选择的配置选项，用来存放内核配置后的结果（如 make config）。
3. arch/*/Makefile：位于各种 CPU 体系目录下的 Makefile，如 arch/arm/Makefile，是针对特定平台的 Makefile。
4. 各个子目录下的 Makefile：比如 drivers/Makefile，负责所在子目录下源代码的管理。
5. Rules.make：规则文件，被所有的 Makefile 使用。

用户通过 make config 配置后，产生了 .config。顶层 Makefile 读入 .config 中的配置选择。顶层 Makefile 有两个主要的任务：产生 vmlinux 文件和内核模块（module）。为了达到此目的，顶层 Makefile 递归的进入到内核的各个子目录中，分别调用位于这些子目录中的 Makefile。至于到底进入哪些子目录，取决于内核的配置。在顶层 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 体系结构下的 Makefile，这个 Makefile 中包含了平台相关的信息。

位于各个子目录下的 Makefile 同样也根据 .config 给出的配置信息，构造出当前配置下需要的源文件列表，并在文件的最后有 include $(TOPDIR)/Rules.make。

Rules.make 文件起着非常重要的作用，它定义了所有 Makefile 共用的编译规则。比如，如果需要将本目录下所有的 c 程序编译成汇编代码，需要在 Makefile 中有以下的编译规则：

        %.s: %.c
        $(CC) $(CFLAGS) -S $< -o $@
        

有很多子目录下都有同样的要求，就需要在各自的 Makefile 中包含此编译规则，这会比较麻烦。而 Linux 内核中则把此类的编译规则统一放置到 Rules.make 中，并在各自的 Makefile 中包含进了 Rules.make（include Rules.make），这样就避免了在多个 Makefile 中重复同样的规则。对于上面的例子，在 Rules.make 中对应的规则为：

        %.s: %.c
        $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@
        

2.2 Makefile 中的变量

顶层 Makefile 定义并向环境中输出了许多变量，为各个子目录下的 Makefile 传递一些信息。有些变量，比如 SUBDIRS，不仅在顶层 Makefile 中定义并且赋初值，而且在 arch/*/Makefile 还作了扩充。

常用的变量有以下几类：

1） 版本信息
版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定义了当前内核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它们共同构成内核的发行版本KERNELRELEASE：2.4.18-rmk7

2） CPU 体系结构：ARCH
在顶层 Makefile 的开头，用 ARCH 定义目标 CPU 的体系结构，比如 ARCH:=arm 等。许多子目录的 Makefile 中，要根据 ARCH 的定义选择编译源文件的列表。

3） 路径信息：TOPDIR, SUBDIRS
TOPDIR 定义了 Linux 内核源代码所在的根目录。例如，各个子目录下的 Makefile 通过 $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定义了一个目录列表，在编译内核或模块时，顶层 Makefile 就是根据 SUBDIRS 来决定进入哪些子目录。SUBDIRS 的值取决于内核的配置，在顶层 Makefile 中 SUBDIRS 赋值为 kernel drivers mm fs net ipc lib；根据内核的配置情况，在 arch/*/Makefile 中扩充了 SUBDIRS 的值，参见4）中的例子。

4） 内核组成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 内核文件 vmlinux 是由以下规则产生的：

vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
	$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o \
		--start-group \
		$(CORE_FILES) \
		$(DRIVERS) \
		$(NETWORKS) \
		$(LIBS) \
		--end-group \
		-o vmlinux

可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 组成的。这些变量（如 HEAD）都是用来定义连接生成 vmlinux 的目标文件和库文件列表。其中，HEAD在arch/*/Makefile 中定义，用来确定被最先链接进 vmlinux 的文件列表。比如，对于 ARM 系列的 CPU，HEAD 定义为：

HEAD            := arch/arm/kernel/head-$(PROCESSOR).o \
                   arch/arm/kernel/init_task.o

表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被链接到 vmlinux 中。PROCESSOR 为 armv 或 armo，取决于目标 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在顶层 Makefile 中定义，并且由 arch/*/Makefile 根据需要进行扩充。 CORE_FILES 对应着内核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，这些是组成内核最为重要的文件。同时，arch/arm/Makefile 对 CORE_FILES 进行了扩充：

# arch/arm/Makefile

# If we have a machine-specific directory, then include it in the build.
MACHDIR         := arch/arm/mach-$(MACHINE)
ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))
SUBDIRS         += $(MACHDIR)
CORE_FILES      := $(MACHDIR)/$(MACHINE).o $(CORE_FILES)
endif

HEAD            := arch/arm/kernel/head-$(PROCESSOR).o \
                   arch/arm/kernel/init_task.o
SUBDIRS         += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpe
CORE_FILES      := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES)
LIBS            := arch/arm/lib/lib.a $(LIBS)

5） 编译信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS
在 Rules.make 中定义的是编译的通用规则，具体到特定的场合，需要明确给出编译环境，编译环境就是在以上的变量中定义的。针对交叉编译的要求，定义了 CROSS_COMPILE。比如：

CROSS_COMPILE   = arm-linux-
CC              = $(CROSS_COMPILE)gcc
LD              = $(CROSS_COMPILE)ld
......

CROSS_COMPILE 定义了交叉编译器前缀 arm-linux-，表明所有的交叉编译工具都是以 arm-linux- 开头的，所以在各个交叉编译器工具之前，都加入了 $(CROSS_COMPILE)，以组成一个完整的交叉编译工具文件名，比如 arm-linux-gcc。
CFLAGS 定义了传递给 C 编译器的参数。
LINKFLAGS 是链接生成 vmlinux 时，由链接器使用的参数。LINKFLAGS 在 arm/*/Makefile 中定义，比如：

# arch/arm/Makefile

LINKFLAGS       :=-p -X -T arch/arm/vmlinux.lds

6） 配置变量CONFIG_*
.config 文件中有许多的配置变量等式，用来说明用户配置的结果。例如 CONFIG_MODULES=y 表明用户选择了 Linux 内核的模块功能。
.config 被顶层 Makefile 包含后，就形成许多的配置变量，每个配置变量具有确定的值：y 表示本编译选项对应的内核代码被静态编译进 Linux 内核；m 表示本编译选项对应的内核代码被编译成模块；n 表示不选择此编译选项；如果根本就没有选择，那么配置变量的值为空。

2.3 Rules.make 变量

前面讲过，Rules.make 是编译规则文件，所有的 Makefile 中都会包括 Rules.make。Rules.make 文件定义了许多变量，最为重要是那些编译、链接列表变量。

O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目录下需要编译进 Linux 内核 vmlinux 的目标文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目标文件使用了 EXPORT_SYMBOL 输出符号。

M_OBJS，MX_OBJS：本目录下需要被编译成可装载模块的目标文件列表。同样，MX_OBJS 中的 "X" 表明目标文件使用了 EXPORT_SYMBOL 输出符号。

O_TARGET，L_TARGET：每个子目录下都有一个 O_TARGET 或 L_TARGET，Rules.make 首先从源代码编译生成 O_OBJS 和 OX_OBJS 中所有的目标文件，然后使用 $(LD) -r 把它们链接成一个 O_TARGET 或 L_TARGET。O_TARGET 以 .o 结尾，而 L_TARGET 以 .a 结尾。

2.4 子目录 Makefile

子目录 Makefile 用来控制本级目录以下源代码的编译规则。我们通过一个例子来讲解子目录 Makefile 的组成：

#
# Makefile for the linux kernel.
#
# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.

export-objs	:= tc.o

# Object file lists.

obj-y		:=
obj-m		:=
obj-n		:=
obj-		:=

obj-$(CONFIG_TC) += tc.o
obj-$(CONFIG_ZS) += zs.o
obj-$(CONFIG_VT) += lk201.o lk201-map.o lk201-remap.o

# Files that are both resident and modular: remove from modular.

obj-m		:= $(filter-out $(obj-y), $(obj-m))

# Translate to Rules.make lists.

L_TARGET	:= tc.a

L_OBJS		:= $(sort $(filter-out $(export-objs), $(obj-y)))
LX_OBJS		:= $(sort $(filter     $(export-objs), $(obj-y)))
M_OBJS		:= $(sort $(filter-out $(export-objs), $(obj-m)))
MX_OBJS		:= $(sort $(filter     $(export-objs), $(obj-m)))

include $(TOPDIR)/Rules.make

a) 注释
对 Makefile 的说明和解释，由#开始。

b) 编译目标定义
类似于 obj-$(CONFIG_TC) += tc.o 的语句是用来定义编译的目标，是子目录 Makefile 中最重要的部分。编译目标定义那些在本子目录下，需要编译到 Linux 内核中的目标文件列表。为了只在用户选择了此功能后才编译，所有的目标定义都融合了对配置变量的判断。
前面说过，每个配置变量取值范围是：y，n，m 和空，obj-$(CONFIG_TC) 分别对应着 obj-y，obj-n，obj-m，obj-。如果 CONFIG_TC 配置为 y，那么 tc.o 就进入了 obj-y 列表。obj-y 为包含到 Linux 内核 vmlinux 中的目标文件列表；obj-m 为编译成模块的目标文件列表；obj-n 和 obj- 中的文件列表被忽略。配置系统就根据这些列表的属性进行编译和链接。
export-objs 中的目标文件都使用了 EXPORT_SYMBOL() 定义了公共的符号，以便可装载模块使用。在 tc.c 文件的最后部分，有 "EXPORT_SYMBOL(search_tc_card);"，表明 tc.o 有符号输出。
这里需要指出的是，对于编译目标的定义，存在着两种格式，分别是老式定义和新式定义。老式定义就是前面 Rules.make 使用的那些变量，新式定义就是 obj-y，obj-m，obj-n 和 obj-。Linux 内核推荐使用新式定义，不过由于 Rules.make 不理解新式定义，需要在 Makefile 中的适配段将其转换成老式定义。

c) 适配段
适配段的作用是将新式定义转换成老式定义。在上面的例子中，适配段就是将 obj-y 和 obj-m 转换成 Rules.make 能够理解的 L_TARGET，L_OBJS，LX_OBJS，M_OBJS，MX_OBJS。
L_OBJS := $(sort $(filter-out $(export-objs), $(obj-y))) 定义了 L_OBJS 的生成方式：在 obj-y 的列表中过滤掉 export-objs（tc.o），然后排序并去除重复的文件名。这里使用到了 GNU Make 的一些特殊功能，具体的含义可参考 Make 的文档（info make）。

d) include $(TOPDIR)/Rules.make

3． 配置文件

3.1 配置功能概述

除了 Makefile 的编写，另外一个重要的工作就是把新功能加入到 Linux 的配置选项中，提供此项功能的说明，让用户有机会选择此项功能。所有的这些都需要在 config.in 文件中用配置语言来编写配置脚本，
在 Linux 内核中，配置命令有多种方式：

以字符界面配置（make config）为例，顶层 Makefile 调用 scripts/Configure， 按照 arch/arm/config.in 来进行配置。命令执行完后产生文件 .config，其中保存着配置信息。下一次再做 make config 将产生新的 .config 文件，原 .config 被改名为 .config.old

3.2 配置语言

1） 顶层菜单
mainmenu_name /prompt/ /prompt/ 是用'或"包围的字符串，'与"的区别是'...'中可使用$引用变量的值。mainmenu_name 设置最高层菜单的名字，它只在 make xconfig 时才会显示。

2） 询问语句

	    bool            /prompt/ /symbol/
        hex             /prompt/ /symbol/ /word/
        int             /prompt/ /symbol/ /word/
        string          /prompt/ /symbol/ /word/
        tristate        /prompt/ /symbol/

询问语句首先显示一串提示符 /prompt/，等待用户输入，并把输入的结果赋给 /symbol/ 所代表的配置变量。不同的询问语句的区别在于它们接受的输入数据类型不同，比如 bool 接受布尔类型（ y 或 n ），hex 接受 16 进制数据。有些询问语句还有第三个参数 /word/，用来给出缺省值。

3） 定义语句

        define_bool     /symbol/ /word/
        define_hex      /symbol/ /word/
        define_int      /symbol/ /word/
        define_string   /symbol/ /word/
        define_tristate /symbol/ /word/

不同于询问语句等待用户输入，定义语句显式的给配置变量 /symbol/ 赋值 /word/。

4） 依赖语句

        dep_bool        /prompt/ /symbol/ /dep/ ...
        dep_mbool       /prompt/ /symbol/ /dep/ ...
        dep_hex         /prompt/ /symbol/ /word/ /dep/ ...
        dep_int         /prompt/ /symbol/ /word/ /dep/ ...
        dep_string      /prompt/ /symbol/ /word/ /dep/ ...
        dep_tristate    /prompt/ /symbol/ /dep/ ...

与询问语句类似，依赖语句也是定义新的配置变量。不同的是，配置变量/symbol/的取值范围将依赖于配置变量列表/dep/ ...。这就意味着：被定义的配置变量所对应功能的取舍取决于依赖列表所对应功能的选择。以dep_bool为例，如果/dep/ ...列表的所有配置变量都取值y，则显示/prompt/，用户可输入任意的值给配置变量/symbol/，但是只要有一个配置变量的取值为n，则/symbol/被强制成n。
不同依赖语句的区别在于它们由依赖条件所产生的取值范围不同。

5） 选择语句

choice          /prompt/ /word/ /word/

choice 语句首先给出一串选择列表，供用户选择其中一种。比如 Linux for ARM 支持多种基于 ARM core 的 CPU，Linux 使用 choice 语句提供一个 CPU 列表，供用户选择：

         choice 'ARM system type' \
        "Anakin                 CONFIG_ARCH_ANAKIN \
         Archimedes/A5000       CONFIG_ARCH_ARCA5K \
         Cirrus-CL-PS7500FE     CONFIG_ARCH_CLPS7500 \
			......
         SA1100-based           CONFIG_ARCH_SA1100 \
         Shark                  CONFIG_ARCH_SHARK" RiscPC
         

Choice 首先显示 /prompt/，然后将 /word/ 分解成前后两个部分，前部分为对应选择的提示符，后部分是对应选择的配置变量。用户选择的配置变量为 y，其余的都为 n。

6） if语句

        if [ /expr/ ] ; then
          /statement/ 
          ...
        fi
        
        if [ /expr/ ] ; then
          /statement/
          ...
        else
          /statement/
          ...
        fi
        

if 语句对配置变量（或配置变量的组合）进行判断，并作出不同的处理。判断条件 /expr/ 可以是单个配置变量或字符串，也可以是带操作符的表达式。操作符有：=，!=，-o，-a 等。

7） 菜单块（menu block）语句

mainmenu_option next_comment
comment '.....'
...
endmenu

引入新的菜单。在向内核增加新的功能后，需要相应的增加新的菜单，并在新菜单下给出此项功能的配置选项。Comment 后带的注释就是新菜单的名称。所有归属于此菜单的配置选项语句都写在 comment 和 endmenu 之间。

8） Source 语句
source /word/
/word/ 是文件名，source 的作用是调入新的文件。

3.3 缺省配置

Linux 内核支持非常多的硬件平台，对于具体的硬件平台而言，有些配置就是必需的，有些配置就不是必需的。另外，新增加功能的正常运行往往也需要一定的先决条件，针对新功能，必须作相应的配置。因此，特定硬件平台能够正常运行对应着一个最小的基本配置，这就是缺省配置。

Linux 内核中针对每个 ARCH 都会有一个缺省配置。在向内核代码增加了新的功能后，如果新功能对于这个 ARCH 是必需的，就要修改此 ARCH 的缺省配置。修改方法如下（在 Linux 内核根目录下）：

1. 备份 .config 文件
2. cp arch/arm/deconfig .config
3. 修改 .config
4. cp .config arch/arm/deconfig
5. 恢复 .config

如果新增的功能适用于许多的 ARCH，只要针对具体的 ARCH，重复上面的步骤就可以了。

3.4 help file

大家都有这样的经验，在配置 Linux 内核时，遇到不懂含义的配置选项，可以查看它的帮助，从中可得到选择的建议。下面我们就看看如何给给一个配置选项增加帮助信息。

所有配置选项的帮助信息都在 Documentation/Configure.help 中，它的格式为：

<description>
<variable name>
<help file>

<description> 给出本配置选项的名称，<variable name> 对应配置变量，<help file> 对应配置帮助信息。在帮助信息中，首先简单描述此功能，其次说明选择了此功能后会有什么效果，不选择又有什么效果，最后，不要忘了写上"如果不清楚，选择 N（或者）Y"，给不知所措的用户以提示。

4． 实例

对于一个开发者来说，将自己开发的内核代码加入到 Linux 内核中，需要有三个步骤。首先确定把自己开发代码放入到内核的位置；其次，把自己开发的功能增加到 Linux 内核的配置选项中，使用户能够选择此功能；最后，构建子目录 Makefile，根据用户的选择，将相应的代码编译到最终生成的 Linux 内核中去。下面，我们就通过一个简单的例子--test driver，结合前面学到的知识，来说明如何向 Linux 内核中增加新的功能。

4.1 目录结构

test driver 放置在 drivers/test/ 目录下：

$cd drivers/test
$tree
.
|-- Config.in
|-- Makefile
|-- cpu
|   |-- Makefile
|   `-- cpu.c
|-- test.c
|-- test_client.c
|-- test_ioctl.c
|-- test_proc.c
|-- test_queue.c
`-- test
    |-- Makefile
    `-- test.c
    

4.2 配置文件

1） drivers/test/Config.in

#
# TEST driver configuration
#
mainmenu_option next_comment
comment 'TEST Driver'

bool 'TEST support' CONFIG_TEST
if [ "$CONFIG_TEST" = "y" ]; then
  tristate 'TEST user-space interface' CONFIG_TEST_USER
  bool 'TEST CPU ' CONFIG_TEST_CPU
fi

endmenu

由于 test driver 对于内核来说是新的功能，所以首先创建一个菜单 TEST Driver。然后，显示 "TEST support"，等待用户选择；接下来判断用户是否选择了 TEST Driver，如果是（CONFIG_TEST=y），则进一步显示子功能：用户接口与 CPU 功能支持；由于用户接口功能可以被编译成内核模块，所以这里的询问语句使用了 tristate（因为 tristate 的取值范围包括 y、n 和 m，m 就是对应着模块）。

2） arch/arm/config.in
在文件的最后加入：source drivers/test/Config.in，将 TEST Driver 子功能的配置纳入到 Linux 内核的配置中。

4.3 Makefile

1）drivers/test/Makefile

#       drivers/test/Makefile
#
#       Makefile for the TEST.
#

SUB_DIRS     :=
MOD_SUB_DIRS := $(SUB_DIRS)
ALL_SUB_DIRS := $(SUB_DIRS) cpu

L_TARGET := test.a
export-objs := test.o test_client.o

obj-$(CONFIG_TEST)              += test.o test_queue.o test_client.o
obj-$(CONFIG_TEST_USER)         += test_ioctl.o
obj-$(CONFIG_PROC_FS)           += test_proc.o

subdir-$(CONFIG_TEST_CPU)       += cpu

include $(TOPDIR)/Rules.make

clean:
        for dir in $(ALL_SUB_DIRS); do make -C $$dir clean; done
        rm -f *.[oa] .*.flags
        

drivers/test 目录下最终生成的目标文件是 test.a。在 test.c 和 test-client.c 中使用了 EXPORT_SYMBOL 输出符号，所以 test.o 和 test-client.o 位于 export-objs 列表中。然后，根据用户的选择（具体来说，就是配置变量的取值），构建各自对应的 obj-* 列表。由于 TEST Driver 中包一个子目录 cpu，当 CONFIG_TEST_CPU=y（即用户选择了此功能）时，需要将 cpu 目录加入到 subdir-y 列表中。

2）drivers/test/cpu/Makefile

#       drivers/test/test/Makefile
#
#       Makefile for the TEST CPU 
#

SUB_DIRS     :=
MOD_SUB_DIRS := $(SUB_DIRS)
ALL_SUB_DIRS := $(SUB_DIRS)

L_TARGET := test_cpu.a

obj-$(CONFIG_test_CPU)       += cpu.o


include $(TOPDIR)/Rules.make

clean:
        rm -f *.[oa] .*.flags
        

3）drivers/Makefile

......
subdir-$(CONFIG_TEST)		+= test
......
include $(TOPDIR)/Rules.make

在 drivers/Makefile 中加入 subdir-$(CONFIG_TEST)+= test，使得在用户选择 TEST Driver 功能后，内核编译时能够进入 test 目录。

4）Makefile

......
DRIVERS-$(CONFIG_PLD) += drivers/pld/pld.o
DRIVERS-$(CONFIG_TEST) += drivers/test/test.a
DRIVERS-$(CONFIG_TEST_CPU) += drivers/test/cpu/test_cpu.a

DRIVERS := $(DRIVERS-y)
......

在顶层 Makefile 中加入 DRIVERS-$(CONFIG_TEST) += drivers/test/test.a 和 DRIVERS-$(CONFIG_TEST_CPU) += drivers/test/cpu/test_cpu.a。如何用户选择了 TEST Driver，那么 CONFIG_TEST 和 CONFIG_TEST_CPU 都是 y，test.a 和 test_cpu.a 就都位于 DRIVERS-y 列表中，然后又被放置在 DRIVERS 列表中。在前面曾经提到过，Linux 内核文件 vmlinux 的组成中包括 DRIVERS，所以 test.a 和 test_cpu.a 最终可被链接到 vmlinux 中。

5． 参考

1. Document/kbuild/makefiles.txt，Linux Kernel Source code
2. Document/kbuild/config-language.txt，Linux Kernel Source code
3. Contributing to the Linux Kernel--The Linux Configuration System，Linux Journal，http://www.linuxjournal.com/categories.php?op=newindex&catid=178
4. Unreliable Guide To Hacking The Linux Kernel，Paul Rusty Russell，rusty@rustcorp.com.au

学习使用SkyEye仿真
SkyEye是一个可以运行嵌入式操作系统的硬件仿真工具，这样就可以在没有硬件条件下来进行嵌入式系统的开发。

以下操作均在Fedora Core 1.0里通过。

文档摘要：
1、什么是SkyEye？
2、SkyEye可以做什么事情？
3、安装SkyEye
4、安装arm-elf交叉编译器
5、测试你的arm-elf-gcc编译器
6、执行你的hello程序
7、编译并运行uClinux-dist-20030909.tar.gz
8、加入网络功能
9、安装完成SkyEye后，下一步将做什么？


1、什么是SkyEye？

SkyEye是开源软件的一个项目，SkyEye的目标是在Linux和Windows操作系统里提供一个完全的仿真环境。SkyEye仿真环境相当于一个嵌入式计算机系统，你可以在SkyEye里运行一些嵌入式Linux操作系统，如ARMLinux，uClinux，uc/OS-II(ucos-ii)等，并能分析和调试它们的源代码。

如果你想知道关于SkyEye和嵌入式系统更详细的信息，请访问下面的站点：
www.SkyEye.org
http://www.skyeye.org/index_cn.html

通过SkyEye能仿真下面的硬件：
CPU核心：ARM7TDMI, ARM720T, ARM9, StrongARM, XScale
CPU: Atmel AT91/X40, Cirrus CIRRUS LOGIC EP7312, Intel SA1100/SA1110, Intel XScale PXA 250/255, CS89712, samsung 4510B, samsung 44B0(还不全)
内存: RAM, ROM, Flash
周边设备: Timer, UART, ne2k网络芯片, LCD, 触摸屏等

目前能在SkyEye上运行下面的操作系统和系统软件：
uC/OSII-2.5.x(支持网络)
uClinux(基于Linux2.4.x内核, 支持网络)
ARM Linux 2.4.x/2.6.x
lwIP on uC/OSII
基于uC/OSII, uClinux, ARM Linux的应用程序


2.SkyEye可以做什么事情？
1. 通过SkyEye可以帮助促进嵌入式系统的学习，在不需要额外硬件的情况下学习和分析uclinux操作系统和其它嵌入式操作系统，如ucosII等。
2. SkyEye可用于嵌入式系统的教学。
3. 希望通过skyeye促进操作系统的研究，如ucosII，uclinux+RTAI，uclinux2.5.x等。
4. 可以基于SkyEye进行仿真特定硬件模块的研究。
5. SkyEye可以作为嵌入式集成开发环境开发嵌入式系统（当然需要对SkyEye做大量的工作）。
注：引自陈渝《SkyEye Project FAQ》


3、安装SkyEye

到http://gro.clinux.org/projects/skyeye/下载skyeye-0.7.0.tar.bz2包：

tar jxvf skyeye-v0.7.0.tar.bz2

进入解压后的skyeye目录，如果SkyEye的版本低于0.6.0,则运行下面的命令：

./configure --target=arm-elf --prefix=/usr/local --without-gtk-prefix --without-gtk-exec-prefix --disable-gtktest

如果SkyEye的版本高于0.6.0,则运行下面的命令：

./configure --target=arm-elf --prefix=/usr/local

接下来执行：

make
make install

安装完成后执行skyeye

注意：
a.如果你使用的是Mandrake Linux发行版,那么你在编译SkyEye时遇到错误，并且错误与readline, ncurse, termcap等有关，你可以试试下面的方法：

ln -s /usr/include/ncurses/termcap.h /usr/local/include/termcap.h

接着再make和make install看能否成功！
b.如果你的Linux发行版是Debian Linux,那么不要使用gcc 2.95或是gcc 3.0，请使用gcc 3.2+
c.gcc的版本要在2.96或以上
d.如果SkyEye的版本大于0.6.0,那么使用LCD仿真需要在Linux系统里安装GTK软件。


4、安装arm-elf交叉编译器

下载arm-elf-tools-20030314.sh
ftp://166.111.68.183/pub/embed/uclinux/soft/tools/arm
或到
ftp://166.111.8.229/OS/Embeded

执行：
chmod a+x arm-elf-tools-20030314.sh
然后：
./arm-elf-tools-20030314.sh

ls /usr/local/bin/

你应能看到以arm-elf开头的可执行文件，其中arm-elf-gcc就是用来编译你目标平台的编译器的，当然还有一些小工具，后面将一一讲来。


5、测试你的arm-elf-gcc编译器

先写一个小程序hello.c

PHP源码:

---

#include <stdio.h>

int main(void)
{
    int i;

    for(i = 0; i < 6; i++){

        printf("i = %d  ",i);

        printf("Hello, embedded linux!\n");
    }

    return 0;
}

---