与其它操作系统相比，Linux最大的特点：它是一款遵循GPL的操作系统，我们可以自由地使用、修改、和扩展它。正是由于这一特色，Linux受到越来越多人士的青睐。于是，一个经常会被探讨的问题出现了，即关于Linux系统的移植。对于操作系统而言，这种移植通常是跨平台的、与硬件相关的，即硬件系统结构、甚至CPU不同。下面就让我们来看看在Linux系统移植方面，我们都需要做些什么。

对于系统移植而言，Linux系统实际上由两个比较独立的部分组成，即内核部分和系统部分。通常启动一个Linux系统的过程是这样的：一个不隶属于任何操作系统的加载程序将Linux部分内核调入内存，并将控制权交给内存中Linux内核的第一行代码。加载程序的工作就完了，此后Linux要将自己的剩余部分全部加载到内存（如果有的话，视硬件平台的不同而不同），初始化所有的设备，在内存中建立好所需的数据结构（有关进程、设备、内存等）。到此为止Linux内核的工作告一段落，内核已经控制了所有硬件设备。至于操作和使用这些硬件设备，则轮到系统部分上场了。内核加载根设备并启动init守护进程，init守护进程会根据配置文件加载文件系统、配置网络、服务进程、终端等。一旦终端初始化完毕，我们就会看到系统的欢迎界面了。小结一下：

(1)内核部分初始化和控制所有硬件设备（严格说不是所有，而是绝大部分），为内存管理、进程管理、设备读写等工作做好一切准备。

(2)系统部分加载必需的设备，配置各种环境以便用户可以使用整个系统。

在进一步叙述之前，我们有必要提一下做系统移植所必需的环境。

首先，需要一个新版本的gcc。对于一个准备系统移植的程序员而言，“新”到什么程度应该心里有数。做跨平台编译，gcc也许是最好的选择。另外，Linux内核依赖许多gcc特有的特性，非它不可。如果你已经会使用gcc并实地操练过多回，那你只需要再进一步巩固一下跨平台编译的操作即可。两种编译环境是可用的：非目标平台上的Linux或目标平台上的非Linux系统，除非你的开发平台过于特殊，否则你一定能够找到你能用的gcc。

其次，编译链接库是必需的，而且必须是目标平台的编译链接库。通常这是一个枯燥、繁琐、又丝毫没有成就感的过程。幸运的话，会有现成的链接库可以用。否则，你需要自己用gcc建立它。

最后，需要目标平台的所有文档，越多越好。如果有一定的开发支持/仿真环境，Loader（加载程序）则最好，这些可以帮助你减少移植过程中浪费在琐事上的时间。

接下来我们从内核和系统两个方面描述一下移植中的关键。

Linux系统采用了相对来说并不是很灵活的单一内核机制，但这丝毫没有影响Linux系统的平台无关性和可扩展性。Linux使用了两种途径分别解决这些问题，很干净利落，丝毫不拖泥带水，而且十分清晰易懂。分离硬件相关代码和硬件无关代码，使上层代码永远不必关心低层换用了什么代码，如何完成了操作。不论对x86上还是在Alpha平台上分配一块内存，对上层代码而言没什么不同。硬件相关部分的代码不多，占总代码量的很少一部分。所以对更换硬件平台来说，没有什么真正的负担。另一方面，Linux使用内核机制很好地解决了扩展的问题，一堆代码可以在需要的时候轻松地加载或卸下，象随身听，需要的时候带上，不需要时则锁在抽屉里。

Linux内核可以视为由五个功能部分组成：进程管理（包括调度和通信）、内存管理、设备管理、虚拟文件系统、网络。它们之间有着复杂的调用关系，但幸运的是，在移植中不会触及到太多，因为Linux内核良好的分层结构将硬件相关的代码独立出来。何谓硬件相关，何谓无关？以进程管理为例，对进程的时间片轮转调度算法在所有平台的Linux中都是一样的，它是与平台无关的；而用来在进程中切换的实现在不同的CPU上是不同的，因此需要针对该平台编写代码，这就是平台相关的。上面所讲的五个部分的顺序不是随便排的，从前到后分别代表着它们与硬件设备的相关程度。越靠前越高，后面的两个虚拟文件系统和网络则几乎与平台无关，它们由设备管理中所支持的驱动程序提供底层支持。因此，在做系统移植的时候，需要改动的就是进程管理、内存管理和设备管理中被独立出来的那部分即硬件相关部分的代码。在Linux代码树下，这部分代码全部在arch目录下。

如果你的目标平台已经被Linux核心所支持的话，那么你是幸运的，因为已经没有太多的工作让你去做。只要你的交叉编译环境是正确的，你只需要简单的配置、编译就可以得到目标代码。否则，需要你去编写，或修改一些代码。只需修改平台相关部分的代码即可。但需要对目标平台，主要是对CPU的透彻理解。在Linux的代码树下，可以看到，这部分的典型代码量为：2万行左右C代码和2千行左右的汇编（C代码中通常包含许多伪汇编指令，因此实际上纯C代码要少很多），这部分工作量是不可小看的。它包含了对绝大多数硬件的底层操作，涉及IRQ、内存页表、快表、浮点处理、时钟、多处理器同步等问题，频繁的端口编程意味着需要你将目标平台的文档用C语言重写一遍。这就是为什么说目标平台的文档极其重要。

代码量最大的部分是被核心直接调用的底层支持部分，这部分代码在arch/xxx/kernel下(xxx是平台名称)。这些代码重写了内核所需调用的所有函数。因为接口函数是固定的，所以这里更象是为硬件平台编写API。不同的系统平台，主要有以下几方面的不同：

* 进程管理底层代码：从硬件系统的角度来看，进程管理就是CPU的管理。在不同的硬件平台上，这有很大的不同。CPU中用的寄存器结构不同，上下文切换的方式、现场的保存和恢复、栈的处理都不同，这些内容主要由CPU开发手册所描述。通常来说，CPU的所有功能和状态对于Linux不一定有意义。实现时，需要在最小的开发代价和最好的系统性能之间加以权衡。

* BIOS接口代码：这一名称似乎并不太准确，因为它沿用了PC一贯的叫法。但在不致引起混淆的情况下我们还是这么叫它。在通用平台上，通常有基本输入输出系统供操作系统使用，在PC上是BIOS，在SPARC上是PROM，在很多非通用系统上甚至并没有这样的东西。多数情况下，Linux不依赖基本输入输出系统，但在某些系统里，Linux需要通过基本输入输出系统中得到重要的设备参数。移植中，这部分代码通常需要完全改写。

* 时钟、中断等板上设备支持代码：即使在同一种CPU的平台上，也会存在不同的板上外设，异种CPU平台上更是如此。不同的系统组态需要不同的初始化代码。很典型的例子就是MIPS平台，看看arc/mips/的代码，与其它系统比较一下就知道。因为MIPS平台被OEM得最广，在嵌入式领域应用最多（相对其它几种CPU而言）。甚至同一种MIPS芯片被不同厂家封装再配上不同的芯片组。因此要为这些不同的MIPS平台分别编写不同的代码。

* 特殊结构代码：如多处理器支持等。其实每一种CPU都是十分特殊的，熟悉x86平台的人都知道x86系列CPU著名的实模式与虚模式的区别，而在SPARC平台上根本就没有这个概念。这就导致了很大的不同：PC机上的Linux在获得控制权后不久就开始切换到虚模式，SPARC机器上则没有这段代码。又如电源管理的支持更是多种多样，不同的CPU有着不同的实现方式（特殊的电源管理方式甚至被厂商标榜）。在这种情况下，除非放弃对电源管理的支持，否则必须重写代码。

还有一部分代码量不多，但不能忽视的部分是在arch/xxx/mm/下的内存管理部分。所有与平台相关的内存管理代码全部在这里。这部分代码完成内存的初始化和各种与内存管理相关的数据结构的建立。Linux使用了基于页式管理的虚拟存储技术，而CPU发展的趋势是：为了提高性能，实现内存管理的功能单元统统被集成到CPU中。因此内存管理成为一个与CPU十分相关的工作。同时内存管理的效率也是最影响系统性能的因素之一。内存可以说是计算机系统中最频繁访问的设备，如果每次内存访问时多占用一个时钟周期，那就有可能将系统性能降低到不可忍受。在Linux系统里，不同平台上的内存管理代码的差异程度是令人吃惊的，可以说是差异最大的。不同的CPU有不同的内存管理方式，同一种CPU还会有不同的内存管理模式。Linux是从32位硬件平台上发展起来的操作系统，但是现在已经有数种64位平台出现。在64位平台上，可用内存范围增大到原来的232倍，其间差异可略窥一斑了。鉴于这部分代码的重要性和复杂性，移植工作在这里变得相当谨慎。有些平台上甚至只是用最保守的内存管理模式。如在SPARC平台上的页面大小可以是多种尺寸，为了简单和可靠起见，SPARC版的Linux只是用了8K页面这一种模式。这一状况直到2.4版才得以改善。

除了上面所讲的之外，还有一些代码需要考虑，但相对来说次要一些。如浮点运算的支持。较完美的做法是对FPU编程，由硬件完成浮点运算。但在某些时候，浮点并不重要，甚至CPU根本就不支持浮点。这时候就可以根据需求来取舍。

对于内核移植的讨论到此为止。实际上，还有一些移植工作需要同时考虑，但很难说这是属于内核范畴还是属于驱动程序范畴，比如说显示设备的支持，和内核十分相关，但在逻辑上又不属于内核，并且在移植上也更像是驱动程序的开发。因此不在这里讨论。

当内核移植完毕后，可以说所有的移植工作就已经完成大半了。就是说，当内核在交叉编译成功后，加载到目标平台上正常启动，并出现类似VFS: Can't mount root file system的提示时，则表示可以开始系统移植方面的工作了。系统移植实际上是一个最小系统的重建过程。许多Linux爱好者有过建立Linux系统应急盘的经验，与其不同的是，你需要使用目标平台上的二进制代码生成这个最小系统。包括：init、libc库、驱动模块、必需的应用程序和系统配置脚本。一旦这些工作完成，移植工作就进入联调阶段了。

一个比较容易的系统部分移植办法是：先着手建立开发平台上的最小系统，保证这套最小系统在开发平台上正确运行。这样可以避免由于最小系统本身的逻辑错误而带来的麻烦。由于最小系统中是多个应用程序相互配合工作，有时出现的问题不在代码本身而在系统的逻辑结构上。

Linux系统移植工作至少要包括上述的内容，除此之外，有一些看不见的开发工作也是不可忽视的，如某个特殊设备的驱动程序，为调试内核而做的远程调试工作等。另外，同样的一次移植工作，显然符合最小功能集的移植和完美移植是不一样的；向16位移植和向64位移植也是不一样的。

在移植中通常会遇见的问题是试运行时锁死或崩溃，在系统部分移植时要好办些，因为可以容易地定位错误根源，而在核心移植时确实很让人头疼。虽然可以通过串口对运行着的内核进行调试，但是在多任务情况下，有很多现象是不可重现的。又如，在初始化的开始，很多设备还没法确定状态，甚至串口还没有初始化。对于这种情况没有什么很好的解决办法，好的开发/仿真平台很重要，另外要多增加反映系统运行状态的调试代码；再者要吃透硬件平台的文档。硬件平台厂商的专业支持也是很重要的。

还有一点很重要：Linux本身是基于GPL的操作系统，移植时，可以充分发挥GPL的优势，让更多的爱好者参与进来，向共同的目标前进。