共享库机制的研究.DOC

附录B Exokernel 共享库(Shared Libraries)机制研究 Exokernel 操作系统为各种应用提供了比较多的底层硬件接口，并允许应用提供各自的操作系统抽象和接口。尽管这样减轻了传统操作系统强加给应用处理局部最优抽象的负担，但是由于应用与大量库操作系统(Library Operating System，简称LibOS)代码的静态连接也造成了内存和磁盘的潜在大量消耗。这样增加了应用的代码长度直接造成高速缓存性能下降，增加了页面到磁盘块的调度，减少了处理载入次数和可能限制了并行运行应用的最大数量。既然应用都期望应用同样的LibOS，或者其中的大部分，把LibOS作为共享库将很好的解决上述问题。但是由于传统载入共享库机制依赖于操作系统高层抽象，把LibOS作为共享库也呈现了如何引导的比较困难的问题，即如何从没有文件或者虚拟内存系统的系统读取文件或虚拟内存的内容. 这篇附录针对上述问题给出了一种解决方案，并主要讨论了其设计和实现行的思想。共享库服务器(Shared Library Server，简称SLS)即是实现的一个例子，它通过一个简单的进程间通信(inter-process communication，简称IPC)接口提供对输入输出(I/O)和虚拟内存(VM)子例程文件的访问权限。在这期间一个小型并与传统共享库载入程序作用一样的启动库建立起来但是通过SLS读取磁盘块中的文件以及载入过程中对虚拟内存的操作。同样，它不依靠LibOS提供的功能。这个启动库也是与应用静态连接，但仅为27k，相比于680k还多的整个LibOS代码来说已经非常少了。这样也极大地减少了应用的大小并加快了处理的执行速度。 1．简介 Exokernels 操作系统为处理与内核的交互提供了一个新的接口。它的设计原则也就是给予应用尽可能多的对硬件资源的控制权限。这种设计去除了大部分的传统内核的抽象，而是由用户层的库操作系统(Library Operating System)来提供。每一个应用都与开发者想用的LibOS相连并成为用户空间代码的一部分。这样操作系统的抽象和接口被定制而基于一个应用，促使各种应用仅对它们要利用的抽象负责。但是如果各种应用不能共享同样的LibOS 而提供传统操作系统的抽象将由于代价太高而难于实现。 如果为每个应用都包括进去大量的LibOS代码将会给性能和资源造成极大的浪费。当我们期望大部分的应用与一个类似于UNIX接口的标准LibOS相连接时，上述大量的代码对许多应用来说是相同的。而且在许多处理过程中都有这么多大量代码的事实也引起了大家对使用共享库(Shared Library)比使用传统操作系统更多的兴趣。 共享库(Shared Libray)机制使多个应用能共享通常的代码集合，同时降低了多余磁盘块和内存的消耗。这些库连接成共享目标文件，当被需要时，就在程序开始运行前被载入并映射到应用程序的地址空间。通常，应用程序拥有一个小的启动代码段以用来在启动时载入所需的共享库进入应用程序的地址空间。这段代码读取存储在应用程序之中并与之相连的共享库的名字和版本数字等数据，利用文件系统和虚拟内存的接口把每一个共享库映射到内存并对共享库中定义的包含正确地址的间接表符号解释。 这个过程由于经常需要依靠更高层的文件系统和内存系统操作来读取磁盘块内的共享库并将它们载入内存，因此实现起来不是非常容易。在传统系统中，这些抽象通常由内核或者通过在运行和对整个系统具有全局意义的子系统提供。然而，在Exokernel 系统中，这些抽象和函数是由LibOS提供的。这样，将LibOS作为共享库载入时就产生了如下引导的问题，即如何从磁盘块把LibOS载入内存，并且这种能力是依靠于LibOS内的代码。 在这篇附录中，这个问题是通过共享库服务器(SLS) 和启动库来解决的。启动库提供了足够的输入/输出(I/O)和内存功能以便将共享库载入一个应用程序处理环境。这是通过为所需操作而设计的受限接口来实现的，这些操作是通过想载入共享库和SLS的进程之间的进程通信来提供的。这样，通过一小部分IPC抽象的实现，以及其它一些基于这些抽象的语义抽象的实现，这个处理过程用有了进入更高曾抽象的功能。 这篇附录描述了SLS的设计和实现以及其它一些对上述问题的解决方案。目前实现的是针对Xok系统，这个系统是基于Intel x86开发的。另外，讨论了有关共享库的相关问题；Exokernel 系统特别是Xok的特性对共享库的影响；讨论了共享库机制的实现；描述了用于实现那样解决方案的设计原则；描述了实现的解决的方案包括设计总览，实现过程中遇到的问题的讨论，解决方