用于提供原地执行功能的系统和方法.pdf

本发明公开了一种操作系统，该操作系统提供了用于实现原地执行功能的新的和发明性的系统和方法。该操作系统提供了用于实现原地执行功能的下面的新的和发明性的功能组件：存储器/文件管理器和至少一个文件系统驱动器之间的文件系统直接访问接口，其中该文件系统直接访问接口提供检索特定文件在特定偏移量处的内容的系统存储器地址的功能，其中文件位于所述存储器寻址设备上；至少一个文件系统驱动器和提供对所述至少一个存储器寻址设备的访问的至少一个设备驱动器之间的设备直接访问接口，其中该设备直接访问接口提供检索至少一个存储器寻址设备的特定块的系统存储器地址的功能；其中通过使用文件系统直接访问接口和设备直接访问接口由该存储器/文件管理器、至少一个文件系统驱动器和提供对至少一个存储器寻址设备的访问的至少一个设备驱动器实现该原地执行功能。

1.  系统(50)，包括：
具有与应用程序(49)的接口(48)的存储器/文件管理器(51)，
至少一个文件系统驱动器(52)，其具有与所述存储器/文件管理器(51)的文件系统I/O接口(45)，
至少一个设备驱动器(44)，其具有到所述文件系统驱动器(52)的设备I/O接口(46)，其中所述至少一个设备驱动器(44)提供对至少一个基于I/O的设备(14)的访问，
至少一个设备驱动器(53)，其具有到所述文件系统驱动器(52)的设备I/O接口(46)，其中所述至少一个设备驱动器(53)提供对至少一个存储器寻址设备(13)的访问，
其中所述操作系统提供原地执行功能以访问至少一个存储器寻址设备(13)，
其特征在于，
所述存储器/文件管理器(51)和所述至少一个文件系统驱动器(52)之间的文件系统直接访问接口(54)，其中所述文件系统直接访问接口(54)提供检索特定文件在特定偏移量处的内容的系统存储器地址的功能，其中所述文件驻留在所述存储器寻址设备(13)上，
所述至少一个文件系统驱动器(52)和提供对所述至少一个存储器寻址设备(13)的访问的所述至少一个设备驱动器(53)之间的设备直接访问接口(55)，其中所述设备直接访问接口(55)提供检索至少一个存储器寻址设备(13)的特定块的系统存储器地址的功能，
其中通过使用所述文件系统直接访问接口(54)和所述设备直接访问接口(55)，由所述存储器/文件管理器(51)、所述至少一个文件系统驱动器(52)和提供对所述至少一个存储器寻址设备(13)的访问的所述至少一个设备驱动器(53)提供所述原地执行功能。

2.  根据权利要求1的系统，其中所述系统是操作系统的一部分或者由所述操作系统提供。

3.  根据权利要求1的系统，其中所述存储器/文件管理器(51)或是使用所述文件系统直接访问接口(54)或是使用所述文件系统I/O接口(45)提供对由所述文件系统驱动器(52)管理的文件的访问。

4.  根据权利要求1的系统，其中所述文件系统驱动器(52)通过检索特定文件在特定偏移量处的内容的系统存储器地址实现所述文件系统直接访问接口(54)，其中所述内容驻留在所述存储器寻址设备(13)的某个块上，通过使用由所述设备驱动器提供的所述设备直接访问接口以便检索所述块的系统存储器地址，由所述设备驱动器提供对该内容的访问。

5.  根据权利要求1的系统，其中通过使用由所述文件系统驱动器(52)提供的所述文件系统直接访问接口(54)检索所述文件在所述偏移量处的内容并使用所述地址原地执行所述内容，所述存储器/文件管理器(51)实现对特定文件在特定偏移量处的原地执行访问，其中所述文件驻留在由所述文件系统驱动器(52)处理的文件系统上，并且所述文件系统驻留在所述存储器寻址设备(13)上。

6.  计算机系统，其具有根据权利要求1-5的系统。

7.  根据权利要求6的计算机系统，该计算机系统具有控制着一个或多个虚拟机的管理程序，其中至少一个虚拟机运行根据权利要求1-5的系统。

8.  根据权利要求7的计算机系统，其中以由所述管理程序给一个或多个所述虚拟机提供的共享存储器段体现所述存储器寻址设备(13)。

9.  用于由根据权利要求1-5的系统自动提供原地执行功能的方法，其中所述系统接受应用程序访问文件的请求，并判定是否使用原地执行功能来访问所述文件，其中所述方法包括以下步骤：
确定保持所述文件的文件系统，
确定管理所述文件系统的文件系统驱动器(52)是否提供所述文件系统直接访问接口(54)，
如果所述文件系统驱动器(52)不提供所述文件系统直接访问接口(54)，则不使用原地执行，
如果所述文件系统驱动器提供所述文件系统直接访问接口(54)，则确定所述文件驻留在其上的设备，
确定管理所述设备(13)的设备驱动器(53)是否提供所述设备直接访问接口(55)，
如果所述设备驱动器不提供所述设备直接访问接口(55)，则不使用原地执行，
确定所述文件系统是否配置成允许原地执行功能，以及
使用所述文件系统直接访问接口(55)提供原地执行功能。

10.  存储在数字计算机的内部存储器内的计算机程序产品，该产品包含软件代码部分，如果在计算机上运行该产品则执行根据权利要求9的方法。

用于提供原地执行功能的系统和方法
技术领域
本发明一般地涉及操作系统，并且具体地涉及提供用于实现原地执行(execute-in-place)功能的系统和方法的操作系统。
背景技术
现有技术的计算机系统包含非易失大容量存储设备(例如硬盘驱动器)以保持程序和数据文件。这些文件的内容必须被装入RAM(“随机访问存储器”)类的系统存储器内以便被CPU(“中央处理单元”)访问或执行。此操作通常由操作系统代表应用程序执行。现有技术的计算机系统和操作系统支持虚拟存储器和按需调页(demand paging)。应用不直接使用系统存储器地址指定它们使用的代码和数据；而是它们使用“虚拟地址”指定存储器位置，由CPU电路实现的且被操作系统控制的调页机制将该存储器位置翻译成系统存储器地址。这使得操作系统可避免必须将全部程序和数据文件装入RAM内。而是系统存储器被分为特定大小的块(被称为“页”)，并且仅在访问该特定页时，操作系统将文件内容的相应块装入各个存储器页内。此过程通常称为“按需调页”。
这种方法的一个缺点是需要RAM以保持程序和数据文件内容，减少了可用于其它用途的RAM的量。另外，通常需要一些时间将内容下载到RAM内。因此，一些现有技术的计算机系统提供了不同类型的非易失存储设备，CPU可用与访问RAM相同的方式直接访问这些不同类型的非易失存储设备(“存储器寻址设备”)。存储器寻址设备的一个现有技术的实施例是快闪存储器卡。存储器寻址设备允许CPU执行该设备上存储的代码和访问该设备上存储的数据而不用首先将内容下载到RAM内。这种直接执行驻留在存储器寻址设备上的代码的方法被称为“原地执行”。为了给在支持虚拟存储器的操作系统上运行的应用提供原地执行功能，该操作系统必须控制调页机制，以便将应用的地址空间的某些虚拟地址映射到该存储器寻址设备支持的地址范围内的系统存储器地址。
其它现有技术的计算机系统提供了虚拟化能力。由通常被称为“管理程序”的运行于单个计算机系统上，但是允许多个“客户”操作系统同时运行的(每个操作系统在一个单独的“虚拟机”内)软件程序实现虚拟化。对于运行在其内的操作系统来说，每个虚拟机自身看起来好像是包括CPU、RAM和I/O设备的真实的计算机系统。由管理程序拦截对这些虚拟组件的访问并且将其翻译成对实际组件的访问。这允许在多个客户操作系统之间共享计算机系统的资源，以提供对系统资源的提高的总的利用率。
一些现有技术的虚拟化计算机系统的一个缺点是如果运行在同一管理程序下的多个客户同时访问相同的程序或数据，则每个客户操作系统将分别分配虚拟RAM以保持这些内容，因此管理程序必须在物理RAM内分配所述内容的多个相同的拷贝。这意味着有较少的存储器可用于其它用途，限制了能够同时有效地运行的客户的数量。因此，一些现有技术的管理程序提供了可从多个客户同时访问的物理存储器的段(“共享存储器段”)。通过将程序或数据文件存储在共享存储器段内，多个客户可同时访问所述文件而不用首先将内容下载到虚拟RAM内。所述共享段在客户操作系统看来就好像是物理存储器寻址设备。
数据和程序文件通常被使用标准文件系统布局存储在设备上；一些操作系统能够使用针对不同使用情况而优化的多种不同的文件系统布局。为此，现有技术操作系统通常被构造为多个组件。在一些操作系统内，存在中央文件和存储器管理组件，多个文件系统驱动器和多个I/O设备驱动器。因此，通过结合中央文件和存储器管理组件使用合适的文件系统驱动器和I/O设备驱动器对，操作系统允许在任何一个支持的I/O设备上使用任何一种支持的文件系统布局。但是，现有技术的操作系统不能使用已有的文件系统驱动器以允许原地执行的方式访问存储器寻址设备。以整体方式实现支持原地执行访问存储器寻址设备。
实际上，一些现有技术的操作系统的实现根本不允许使用标准文件系统布局将数据存储在存储器寻址设备上；而是它们需要以设备专用的方式将数据布置在这种设备上。该布置具有许多缺点，对于使用I/O设备和存储器寻址设备的计算机系统尤其如此。支持不同文件系统布局可使得系统管理更加困难。可能需要不同的工具来格式化、管理、备份和恢复不同布局。从I/O设备将一组已有文件移植到存储器寻址设备可能更加困难，反之亦然。存储器寻址设备所需的特定布局可能不提供标准文件系统布局所具有的所有特征(例如，实现复杂的访问控制和特权检查)。
另一种现有技术的实现(zSeries上用于Linux地XIP2FS文件系统)提供使用第二扩展文件系统(“ext2”)格式一Linux操作系统提供的一种标准文件系统格式一将程序和数据存储在虚拟存储器寻址设备(由z/VM管理程序提供的共享存储器段)上的支持。但是，此方法仍具有大部分前面段落内所述的缺点：不能使用其它的标准Linux文件系统格式，并且另外XIP2FS不能提供ext2的所有特征(例如XIP2FS不支持写访问)。
XIP2FS的另一个缺点是其不能被集成到操作系统的上述组件结构内；尽管XIP2FS使用ext2文件系统布局访问文件，XIP2FS不使用Linux ext2文件系统驱动器这样做，而是重新实现访问ext2文件系统布局所需的访问逻辑。这再次使得XIP2FS不支持ext2的所有特征，因为只有整个ext2逻辑的子集被重新实现。作为另一个缺点，随着时间的过去Linux操作系统的标准ext2文件系统组件不断被发展并且添加新特征；例如由Linux内核版本2.6提供的ext2文件系统驱动器版本增加了对更快地访问非常大的目录结构以及更复杂的访问控制机制的支持。XIP2FS不能自动地受益于对ext2驱动器的这种改进；所有所需的特征需要在XIP2FS代码内被重新实现。
发明内容
本发明的目的是提供一种由避免上述现有技术的缺点的操作系统提供原地执行功能的方法。
本发明公开了一种提供了用于实现原地执行功能的新系统和方法的操作系统。
本发明基于其上的现有技术的操作系统包括具有与应用程序的接口的存储器/文件管理器，至少一个文件系统驱动器，其具有与存储器/文件管理器的文件系统I/O接口，至少一个设备驱动器，其具有与文件系统驱动器的设备I/O接口，其中所述至少一个设备驱动器提供到至少一个基于I/O的设备的访问，至少一个设备驱动器，其具有与文件系统驱动器的设备I/O接口，其中所述至少一个设备驱动器提供到至少一个存储器寻址设备的访问，其中所述操作系统提供原地执行功能以访问至少一个存储器寻址设备。
以下面的新的和发明性的功能扩展现有技术的操作系统以实现原地执行功能：
存储器/文件管理器和至少一个文件系统驱动器之间的文件系统直接访问接口，其中该文件系统直接访问接口提供了检索特定文件在特定偏移量处的内容的系统存储器地址的功能，其中该文件驻留在所述存储器寻址设备上，
至少一个文件系统驱动器和提供到所述至少一个存储器寻址设备的访问的至少一个设备驱动器之间的设备直接访问接口，其中该设备直接访问接口提供了检索至少一个存储器寻址设备的特定块的系统存储器地址的功能，
其中通过使用文件系统直接访问接口和设备直接访问接口，由存储器/文件管理器、至少一个文件系统驱动器和提供到至少一个存储器寻址设备的访问的至少一个设备驱动器实现原地执行功能。
附图说明
从下面的详细说明中可清楚地了解本发明的上述以及另外的目的、特征和优点。
在所附权利要求中提出了本发明的新颖特征。但是，当结合附图阅读时通过参考下文对说明性实施例的详细说明，可以最好地理解本发明本身以及其优选使用模式、另外的目的和其优点，其中：
图1A示出实现本发明所需的计算机系统的框图；
图1B示出在本发明的一些实施例中容纳有图1A所示的计算机系统作为客户的虚拟机环境；
图1C示出现有技术的操作系统提供的虚拟存储器和按需调页功能；
图1D示出现有技术的操作系统提供的原地执行功能；
图1E示出实现原地执行的现有技术操作系统的组件结构；
图2A示出使用本发明实现原地执行的操作系统的组件结构；
图2B示出根据本发明用于访问基于I/O的设备的图2A的操作系统组件中的控制流；
图2C示出根据本发明用于执行对存储器寻址设备的原地执行访问的图2A的操作系统组件中的控制流；
图2D是用于选择使用图2B和2C所示的两个控制流中的哪一个的图2A的操作系统的判定逻辑；
图3A示出现有技术的Linux操作系统内实现的设备抽象；
图3B示出对实现本发明的Linux操作系统内的设备驱动层进行的扩展；
图3C示出通用文件系统如何服务于地址空间操作以便从/向现有技术的Linux操作系统内的设备读/写一个或多个页；
图3D示出对实现本发明的Linux操作系统内的文件系统的地址空间操作进行的扩展；
图3E示出在现有技术的Linux操作系统中文件系统库函数如何执行通用文件系统的读类型文件操作；
图3F示出对用于实现本发明的Linux操作系统内的读类型操作的文件系统库函数进行的扩展；
图3G示出在现有技术的Linux操作系统中文件系统库函数如何执行通用文件系统的写类型文件操作；
图3H示出对用于实现本发明的Linux操作系统内的写类型操作的文件系统库函数进行的扩展；以及
图3I示出对用于实现本发明的Linux操作系统内的文件存储器映射的文件系统库函数进行的扩展。
具体实施方式
图1A示出计算机系统10的框图。计算机系统10可以是个人计算机、大型计算机或任何其它类型的计算机或数据处理系统；如下文所述，计算机系统10还可以是由另一计算机系统上运行的管理程序提供的虚拟机。计算机系统10包括中央处理单元(“CPU”)11、随机访问存储器(“RAM”)12、存储器寻址设备13和基于I/O的设备14。在一个实施例中，存储器寻址设备13可以是闪速存储器卡。在另一个实施例中，存储器寻址设备13可以是CPU 11可直接访问以进行存储器操作的任何设备。在一个实施例中，基于I/O的设备14可以是硬盘驱动器。在其它实施例中，基于I/O的设备14可以是允许使用I/O操作向和从RAM 12拷贝数据的任何设备。计算机系统10还可包括存储器寻址设备13和/或基于I/O的设备14的多个实例。CPU 11、RAM 12以及设备13和14可连接到系统总线15。CPU11可直接访问RAM 12和存储器寻址设备13以进行存储器操作。CPU 11不能直接访问基于I/O的设备14以进行存储器操作，但是可使用I/O操作将数据从设备14拷贝到RAM 12，反之亦然。计算机系统10运行允许运行一个或多个应用程序的操作系统(下文将更详细地说明)；该操作系统管理和调节应用程序对计算机系统10的各种资源(CPU 11、RAM 12、设备13和14)的访问。
在一些实施例中，计算机系统10可以是在另一个计算机系统上运行的管理程序仿真的虚拟机。图1B示出了这样的实施例，其中计算机系统10包含虚拟CPU 11、虚拟RAM 12以及虚拟设备13和14。由管理程序21提供所有虚拟组件，该管理程序是在本身包含CPU、RAM和设备的另一个计算机系统20上运行的软件程序。管理程序21或是完全用软件或是通过使用计算机系统20提供的虚拟化硬件辅助功能提供虚拟组件10-14。除了虚拟机10之外，可在计算机系统20上的管理程序21下同时运行其它虚拟机22。在一个实施例中，管理程序21可以是运行在IBM eServerzSeries大型计算机上的IBM公司制造和销售的z/VM软件程序。在此实施例内，计算机系统10可以是z/VM提供的虚拟机，并且存储器寻址设备13可以是定义于z/VM之下并且虚拟机可用的不连续保存分段(“DCSS”)。DCSS是同时可被一个或多个虚拟机使用的由z/VM管理的存储器段；即使得DCSS同时可被多个虚拟机使用，z/VM通常仅在计算机系统20的真实RAM内保持DCSS内容的单个拷贝。
如图1C所示，CPU 11可直接访问以进行存储器操作的所有组件构成计算机系统10的系统存储器地址空间30。RAM 12和存储器寻址设备13是系统存储器地址空间30的一部分；另外，其它组件(未示出)例如只读存储器(“ROM”)或视频卡帧缓冲器也可以是系统存储器地址空间30的一部分。在发生执行时，CPU 11执行的每个程序指令和CPU 11执行的指令所访问的所有存储器数据必须出现在系统存储器地址空间30内。为了增加可用存储器表面上的大小，并且防止同时运行在相同计算机系统上的不同应用程序意外地修改彼此的存储器，操作系统为每个应用程序提供“虚拟地址空间”，并且在该虚拟地址空间内提供对系统存储器地址空间的所选择部分的访问。当CPU 11执行应用代码时，可以仅访问出现在应用的虚拟地址空间内的存储器。为了在虚拟地址空间和系统存储器地址空间之间转换，将虚拟地址空间和系统存储器地址空间两者分成相等大小的块，该块通常被称为“页”。
图1C示出了计算机系统10的系统存储器地址空间30。另外示出了应用程序的虚拟地址空间31。对于可在虚拟地址空间31内寻址的每个页，必须存在描述页的实际状态的页描述符。在任何时刻该页可存在于或不存在于系统存储器地址空间30内。如果页存在于系统存储器地址空间30内，页描述符将指出该事实并且将指出页在系统存储器地址空间30内的位置。如果页不存在于系统存储器地址空间30内，则页描述符将指出该事实并且将包含附加信息，该附加信息允许操作系统定位应用程序希望通过该页访问的内容。用于虚拟地址空间的所有页描述符的集合称为页表。由操作系统保持用于虚拟地址空间的页表。
当CPU 11执行虚拟地址空间31内的应用代码时，使用用于虚拟地址空间31的页表将CPU 11访问的每个存储器地址从虚拟地址空间31内的虚拟地址转换到系统存储器地址空间30的系统存储器地址。由调页机制执行该转换，调页机制可以是硬件或软件实现或者是两者的组合。对于一些实施例，由存在于CPU 11内的调页单元实现调页机制。当CPU 11访问目前在系统存储器地址空间30内不具对应页的虚拟地址空间31内的页时，该调页机制使CPU 11产生页错误中断。该中断使被称为“页错误处理器”的操作系统代码将所需的内容放入系统存储器地址空间30内的某页内并更新页表，以便将该虚拟页映射到系统存储器地址空间30内的该页。然后应用可以继续运行并访问该页。此过程通常被称为“按需调页”。
在图1C所示的示例情况下，虚拟地址空间31同时保持四个页。三个页(32a-32c)包含目前执行的应用代码，一个页(32d)包含该应用访问的数据。从驻留在基于I/O的设备14上的块34a-34c内的应用程序文件装入页32a-32c内包含的应用代码。实际上应用代码页32a和32b目前存在于系统存储器地址空间30内，并驻留在RAM 12的页33a和33b内；类似的，数据页32d存在于系统存储器地址空间内，并驻留在RAM 12的页33d内。应用代码页32c目前不存在于系统存储器地址空间30内。一旦应用访问页32c，操作系统的页错误处理器将在RAM 12内分配新页33c(未示出)，执行I/O操作以便将块34c的内容拷贝到页33c内，并更新页表以便将虚拟地址空间31的页32c映射到系统存储器地址空间30的页33c。对于页32a和32b，在图1C所示的时刻此过程已经完成。数据页32d/33d保持应用在运行时产生的内容，它不被从基于I/O的设备14装入。
如图1C中可见，当CPU 11执行驻留在基于I/O的设备14上的应用程序时，需要RAM 12的页以便在执行应用程序代码时保持该应用程序代码。但是，如果应用程序驻留在存储器寻址设备上，这是不需要的，使得更多的RAM 12页可用于其它用途(或者可选择地，允许计算机系统10以较少的RAM总量完成其预期任务)。此过程通常被称为“原地执行”。如同图1C，图1D示出了运行在虚拟地址空间内的相同的应用，但是应用现在驻留在存储器寻址设备13上而不是基于I/O的设备14上并且被原地执行。如图1D中所示，来自应用文件的应用代码驻留在存储器寻址设备13的块35a-c内。因为存储器寻址设备13存在于系统存储器地址空间30内，可分别将块35a和35b直接映射到虚拟地址空间31的页32a和32b。类似地，一旦应用访问页32c，操作系统的页错误处理器将简单地在虚拟地址空间31的页32c和系统存储器地址空间30的页35c之间建立另一个映射；操作系统不需要在RAM 12内分配任何页。但是应指出，如在图1C内所示的，数据页32被映射到RAM 12的页33d。
图1E设想了不包含本发明的现有技术的操作系统40的组件结构。仅示出了实现图1C和1D内所示的按需调页和原地执行功能所需的那些组件。操作系统40包含存储器/文件管理器41，该管理器处理通过接口48来自应用程序49的请求以访问驻留在基于I/O的设备14上或存储器寻址设备13上的文件。为了访问基于I/O的设备14上的文件，存储器/文件管理器41通过文件系统I/O接口45与文件系统驱动器43交互，文件系统驱动器43继而通过设备I/O接口46与设备驱动器44交互。操作系统40可包含多个版本的文件系统驱动器，每个驱动器负责处理特定的文件系统类型；每个文件系统驱动器实现相同的文件系统I/O接口45。类似的，操作系统40可包含多个版本的设备驱动器，每个设备驱动器负责处理特定的设备类型；每个设备驱动器实现相同的设备I/O接口46。
在如图1E所示的操作系统40的组件结构内，设备驱动器44(以及所有设备驱动器)的职责是将数据从基于I/O的设备上的特定位置拷贝到RAM内，反之亦然。该设备驱动器不具有关于设备内容或者这些内容的组织方式的任何知识。通常将驻留在设备上的数据分成被称为“块”的块，以“块号”标识每个块。设备I/O接口46允许设备驱动器请求将数据从以块号B标识的块拷贝到以地址A开始的RAM的块内，反之亦然。
为了允许实现数据在设备上的结构化存储，操作系统40提供文件系统驱动器。文件系统驱动器允许访问作为“文件”的集合存储在设备上的数据，每个文件提供有序字节序列的抽象。由文件系统提供的一些方法标识每个文件，通常是“文件名”。文件系统跟踪每个文件的哪些字节存储在底层设备的哪些块内。执行该记录保持所需的信息通常被称为“文件系统元数据”，并且其本身被存储在底层设备上。文件系统元数据的特定布局因文件系统不同而不同。在如图1E内所示的操作系统40的组件结构内，文件系统驱动器43(以及所有文件系统驱动器)职责是实现所有必要的逻辑以处理文件系统元数据布局。文件系统I/O接口45允许文件系统驱动器请求将数据从以某个文件名标识的文件F从文件F内的特定偏移量O开始拷贝到以地址A开始的RAM的块，反之亦然。为了处理这样的请求，文件系统驱动器将参考文件系统元数据以确定底层设备的哪个块B保持有对应于文件F内的偏移量O的数据，并使用处理底层设备的设备驱动器的设备I/O接口46在所述设备的块B和存储器的特定块之间拷贝数据。
在如图1E所示的操作系统40的组件结构内，图1C内示出的按需调页功能被如下实现：当应用访问目前不存在于系统存储器地址空间内的页时，操作系统的页错误处理器(通常是存储器/文件管理器41的一部分)将从页描述符确定该应用希望该页具有的内容。通过指出发现所述内容的文件F和文件F内的偏移量O，页描述符标识所述内容。然后存储器/文件管理器41将在RAM 12内分配新页，并通过文件系统I/O接口45请求文件系统驱动器43将数据从文件F内的偏移量O拷贝到所述新页内。如上所述，文件系统驱动器43将参考文件系统元数据确定底层设备(在此情况下为基于I/O的设备14)的哪个块B保持该数据，并且然后使用设备驱动器44的设备I/O接口46将该数据拷贝到所述新页内。一旦I/O操作完成，存储器/文件管理器41将相应地更新页表。
但是，不能使用文件系统驱动器43对驻留在存储器寻址设备13上的文件执行原地执行访问，这是因为现有技术的文件系统I/O接口45不适合于该目的。而是在如图1E所示的操作系统40的组件结构内，由XIP管理器42处理原地执行访问，XIP管理器42紧密地集成在存储器/文件管理器41内，并直接访问存储器寻址设备13。因此XIP管理器42负责实际访问存储器寻址设备13和处理存储在所述设备上的数据的文件系统布局。不能使用XIP管理器42所支持的那些文件系统布局之外的任何其它文件系统布局访问存储器寻址设备13上的数据，即使操作系统40另外为这样的文件系统提供文件系统驱动器也是如此。
本发明除去了此限制。图2A示出了包含本发明的实现了对存储器寻址设备13的原地执行访问的操作系统50的组件结构。与图1E中所示的现有技术的操作系统40相比，操作系统50保持了到计算机系统10的所有硬件组件(RAM 12、基于I/O的设备14、存储器寻址设备13)的相同接口。其还使用到应用程序49的相同接口48。存储器/文件管理器51是现有技术提供的存储器/文件管理器41(见图1E)的修改版本，并且文件系统驱动器52是现有技术提供的文件系统驱动器43(见图1E)的修改版本。操作系统50还提供了访问存储器寻址设备13的设备驱动器53。应指出，操作系统40的某些现有技术的版本也提供类似的访问存储器寻址设备13的设备驱动器，但是这种驱动器仅实现了设备I/O接口46(见图1E)，并且不能提供原地执行功能。此功能由XIP管理器42实现，但是该管理器直接访问存储器寻址设备13而不使用任何设备驱动器。如图2A中所示，本发明不再需要XIP管理器组件。而是现在将原地执行功能集成在现有的组件存储器/文件管理器51、文件系统驱动器52和设备驱动器53内。这可通过使用两个新的接口来实现：由文件系统驱动器52提供的文件系统直接访问接口54，和由设备驱动器53提供的设备直接访问接口55。设备直接访问接口55的核心特征是提供检索存在于系统存储器地址空间内的存储器寻址设备的块B的系统存储器地址A的方法。类似的，文件系统直接访问接口54的核心特征是提供检索文件F在偏移量O处的内容的系统存储器地址A的方法，其中文件F驻留在存在于系统存储器地址空间内的存储器寻址设备上。下面将更详细地描述这些直接访问接口的使用。
如图2A所示，操作系统50通过接口48与应用程序49交互。接口48的一部分包含由应用程序49触发的按需调页请求，应用程序49访问目前没有被映射到系统存储器地址空间30的页的其虚拟地址空间31的页(应指出，虚拟地址空间31和系统存储器地址空间30如图1C和1D中所示，其中虚拟地址空间31对应于应用49的虚拟地址空间)。接口48的其它部分包含应用程序49对操作系统50的请求(“系统调用”)以便读、写或访问驻留在基于I/O的设备14或存储器寻址设备13上的文件的内容。存储器/文件管理器51是操作系统50的处理应用程序49通过接口48发出的请求的组件。为了访问驻留在基于I/O的设备14或存储器寻址设备13上的文件的内容，存储器/文件管理器51通过文件系统I/O接口45和/或文件系统直接访问接口54与文件系统驱动器52交互。操作系统50可包含多个版本的文件系统驱动器，每个版本负责处理特定的文件系统布局。所有文件系统驱动器实现相同的文件系统I/O接口45，并且一些文件系统驱动器实现附加的文件系统直接存储接口54，其适合于对驻留在存储器寻址设备上的文件执行原地执行访问。文件系统驱动器52通过设备I/O接口46和/或设备直接访问接口55与设备驱动器44和53交互。操作系统50还可包含多个版本的设备驱动器，每个驱动器负责处理特定类型的设备。所有设备驱动器实现相同的设备I/O接口46，并且用于存储器寻址设备13的设备驱动器还附加地实现设备直接访问接口55，其适于对驻留在存储器寻址设备13上的文件执行原地执行访问。
对于提供I/O接口45和直接访问接口54两者的文件系统驱动器，存储器/文件管理器51能够对由这种文件系统驱动器处理的文件执行常规访问和原地执行访问。图2B和2C分别更详细地示出执行常规和原地执行访问所需的控制流。图2D将详细地示出对于任何特定的文件访问选择使用两种方法中的哪一种所需的判定逻辑。
图2B示出了当操作系统50处理访问驻留在基于I/O的设备14上的文件的请求时的控制流。应指出，此控制流等同于现有技术的操作系统40为相应的访问所使用的控制流。依次用动作60a-f表示该控制流的步骤。在应用49已试图访问虚拟地址空间31的页32c之后，这里示出的特定动作相应于图1C所示的情况。由于该页目前没有被映射到系统存储器地址空间30的任何页，所以由操作系统50的存储器/文件管理51组件产生并且处理页错误中断。在图2B中这被以动作60a表示。存储器/文件管理器51从页32c的页描述符读出该应用希望其内容相应于文件F在偏移量O处的内容。其确定文件F驻留在由文件系统驱动器52处理的文件系统上。其还确定文件F不支持原地执行(这将在下文更详细地说明)。然后其在RAM 13分配空闲页33c并确定其系统存储器地址A，并且通过文件系统驱动器52的文件系统I/O接口45请求将文件F在偏移量O处的内容拷贝到系统存储器地址A处的页(动作60b)。文件系统驱动器52确定文件F在偏移量O处的数据驻留在基于I/O的设备14的块B上，并且设备驱动器44负责访问基于I/O的设备14。然后通过设备驱动器44的设备I/O接口46请求将基于I/O的设备14的块B拷贝到系统存储器地址A处的页(动作60c)。设备驱动器44在基于I/O的设备44上实现I/O操作61以执行该拷贝。一旦I/O操作61已完成，设备驱动器44通过设备I/O接口46将完成报告给文件系统驱动器52(动作60d)，其类似地通过文件系统I/O接口45将完成报告给存储器/文件管理器51(动作60e)。存储器/文件管理器51最终建立虚拟地址空间31的页32c到系统存储器地址空间30的地址A处的页33c的映射，页33c现在保持所请求的内容(动作60f)。
图2C类似地示出了当操作系统50处理请求以便对驻留在存储器寻址设备13上的文件执行原地执行访问时的控制流。应指出，此流程不同于现有技术操作系统40为相应的访问所使用的流程，并且使用本发明所描述的新的直接访问接口。还应注意，对基于存储器的设备13上的文件的某些访问可能不适合于原地执行访问；在这样的情况下取而代之使用上面描述的如图2B给出等同的控制流执行对该文件的常规I/O访问。由于设备驱动器53像设备驱动器44那样也实现了设备I/O接口46，所以这是可能的。
由动作70a-f依次表示图2C中所示的控制流的步骤。在应用49已试图访问虚拟地址空间31的页32c之后，这里所示的特定动作相应于图1D所示的情况。如图2B，由存储器/文件管理器51产生和处理页错误中断(动作70a)，存储器/文件管理器51再次从页32c的页描述符读出该应用希望其内容应相应于文件F在偏移量O处的内容。其再次确定文件F驻留在由文件系统驱动器52处理的文件系统上。其还确定文件F支持原地执行(这将在下文更详细地说明)。现在它通过文件系统驱动器52的文件系统直接访问接口请求检索文件F在偏移量O处的内容的系统存储器地址(动作70b)。文件系统驱动器52确定文件F在偏移量O处的内容驻留在存储器寻址设备13的块B上，并且设备驱动器53负责访问存储器寻址设备13。然后它通过设备驱动器53的设备直接访问接口55请求检索存储器寻址设备13的块B的系统存储器地址(动作70c)。设备驱动器53确定存储器寻址设备13的块B相应于系统存储器地址空间30的页35c，并通过设备直接访问接口55将其地址A返回文件系统驱动器52(动作70d)，文件系统驱动器52类似地通过文件系统直接访问接口54将地址A返回存储器/文件管理器51(动作70e)。存储器/文件管理器51最终建立虚拟地址空间31的页32c到系统存储器地址空间30的地址A处的页35c的映射(动作70f)。
图2D示出了当确定使用文件系统I/O接口还是使用文件系统直接访问接口访问文件F时操作系统50(图2A)内的控制流。操作系统首先确定哪个文件系统驱动器负责用于保持着文件F的文件系统FS。如果该文件系统驱动器根本不支持文件系统直接访问接口，则使用文件系统I/O接口。否则，操作系统确定哪个设备驱动器负责用于文件系统FS的底层设备D。如果该设备驱动器根本不支持设备直接访问接口，则也使用文件系统I/O系统接口。否则，操作系统确定文件系统FS是否被用户配置为对文件F进行原地执行访问。如果是，则使用文件系统直接访问接口，否则使用文件系统I/O接口。在一些实施例中，用户仅可以选择允许对FS上的所有文件进行原地执行访问或是对所有文件都不进行原地执行访问。在其它实施例中，用户可对每个单独的文件分别进行选择。另外，在一些实施例中，如果其它可配置的文件系统参数已被用户设置为与原地执行相兼容的值，才可以允许原地执行访问；例如必须将文件系统块的大小配置成等于或者是系统存储器页大小的数倍的值。
注意操作系统不必为对文件F的每一个访问执行图2D所示的整个判定逻辑。而是当第一次访问文件F时进行一次选择，并且在与文件F相关联的操作系统数据结构内加以记忆；随后的访问将重新使用在所述数据结构内存储的该判定的结果。
图3A-I更详细地示出了Linux操作系统内的本发明的一个实施例。通过扩展标准操作系统I/O组件结构的接口而不是整个替换它，本发明将原地执行功能集成在标准操作系统I/O组件结构内。Linux提供了下述与执行I/O操作有关的组件层：
设备驱动层，其允许访问背后的存储设备而不需要所涉及的特定硬件的知识，
文件系统层，其允许使用逻辑文件视图访问背后的存储设备而不需要关于背后的存储设备的知识，
存储器管理层，其允许执行应用而不需要该应用了解操作系统使用的虚拟存储器和动态地址转换技术。
图3A示出了在许多现代操作系统内实现的设备抽象。该例子示出了Linux内的设备驱动器。调用make_request函数以便提交从/向该设备读/写数据的请求。request_queue和do_request函数是Linux内的优化的一部分。设备驱动器将按循环“发送请求→处理请求→中断处理器→发送请求”运行，直到提交给它的所有工作被完成为止。
设备驱动层允许提交读或写请求。该层的频繁的用户是文件系统的读页(多个)/写页(多个)操作，它们从/向文件传输数据。为了对所述数据寻址，使用物理块号。
如图3B内所示，本发明提供了对设备驱动器层的接口的扩展。在保持现有接口不动的同时，该扩展提供了可用于得到设备上的数据的直接引用的功能。可使用此引用访问设备上的数据而不需要提交请求并等待它们的完成。此扩展可选择地可由访问存储器寻址设备的设备驱动器实现。新的操作direct_access获得与make_request类似的块号，但是不传输任何数据。而是返回对数据的引用。在此后的任何时间可使用此引用向该物理块读或写任何数据直到再次关闭/卸载该设备而不需要与设备驱动层进行其它交互。新接口的使用是可选的，对于不支持新接口的用户例如原始设备驱动器，传统的make_request接口保持不动。对于支持通用的文件系统，传统接口是重要的，通用的文件系统使用传统接口传输文件系统元数据(i节点、目录项等)。
图3C示出了Linux内的通用的文件系统如何可以使用设备驱动器的make_request函数实现地址空间操作。readpage(s)/writepage(s)函数使用get_block函数[在处理多个页时重复执行]标识与目的页(多个)相关联的设备上的物理块号(多个)。如图3A所示的make_request函数用于访问数据。在Linux内，文件系统通常与文件系统库函数一起使用地址空间操作以执行文件操作例如sys_read()和sys_write()。这些地址空间操作和库函数的使用是可选择的，但是大部分通用文件系统使用它们。地址空间操作readpage()、readpages()、writepage()和writepages()被用来从/向设备驱动器读/写一个或多个存储器页的数据。为了寻址存储器页，使用逻辑文件句柄和偏移量。该寻址被文件系统转换成物理块号。
如图3D所示，本发明以名为“get_xip_page”的函数提供了对地址空间操作接口的扩展，get_xip_age函数允许检索对给定存储器页之后的存储的引用。该函数使用文件句柄和偏移量以便进行寻址，通过调用get_block函数将其转换成物理块号，并从设备驱动器层的direct_access函数检索对该物理块之后的存储的引用(如图3B所示)。此后的任何时间可使用此引用向该物理块读或写任何数据，直到该文件被删简或文件系统被卸载而不需要与文件系统或设备驱动器层的其它交互。当被支持时新接口的使用是强制性的，出于数据完整性的原因，对于一个文件或是支持传统的readpage(s)/wirtepage(s)接口或是新的get_xip_page接口。文件系统可基于每个文件自由选择。
readpage(s)/wirtepage(s)函数的主要用户是文件系统库函数。图3E示出了在Linux内文件系统库函数如何为通用文件系统执行读类型的文件操作。
Generic_file_read函数执行与sys_read()系统调用相关联的文件操作。
Generic_file_readv函数执行与sys_readv()系统调用相关联的文件操作。
Generic_file_aio_read函数执行与异步IO系统调用相关联的读操作。
Generic_file_sendfile文件操作执行与sys_sendfile()系统调用相关联的文件操作。
所有这些函数间接地调用generic_mapping_read，generic_mapping_read使用readpage(s)函数(如图3C内所示)从设备读一个或多个页。虽然对于文件系统这些函数的使用是可选择的，但是大多数通用文件系统使用它们而不是自己实现文件操作。
图3G示出了在Linux内文件系统库函数如何为通用文件系统执行写类型的文件操作。
Generic_file_write函数执行与sys_write()系统调用相关联的文件操作。
Generic_file_writev函数执行与sys_writev()系统调用相关联的文件操作。
Generic_file_aio_write函数执行与异步IO系统调用相关联的写操作。
所有这些函数间接地调用generic_file_direct_write(当使用选项O_DIRECT打开目标文件时)或generic_file_buffered_write。这两个函数使用writepage(s)函数向设备写一个或多个页。
本发明提供了对这些库函数的扩展以便使得它们在被支持时能够使用get_xip_page接口。图3F示出了对读类型操作的文件系统库函数的扩展。根据是否出现get_xip_page地址空间操作，使用generic_mapping_read函数或新的do_xip_mapping_read函数执行该操作。do_xip_mapping_read函数使用get_xip_page地址空间操作以检索该设备上的目标数据的引用。对于数据传输，直接使用此引用而不需执行I/O操作。图3H示出了对写类型操作的文件系统库函数的扩展。根据是否出现get_xip_page地址空间操作，使用generic_file_buffered_write/generic_file_direct_write函数或新的generic_file_xip_write函数执行该操作。generic_file_xip_write函数使用get_xip_page地址空间操作以检索该设备上的目标数据的引用。对于数据传输，直接使用此引用而不需执行I/O操作。
实现get_xip_page地址空间操作的所有文件系统不需要其它的代码改变以便以由库函数实现的所有文件操作执行原地执行访问。图3F、3H和3I示出了扩展的库函数如何根据是否实现了get_xip_page地址空间操作实行它们的功能。当实现了get_xip_page时，所有库函数使用从get_xip_page检索到的引用直接执行到该存储设备的所有数据传输。图3I示出了对用于文件存储器映射的文件系统库函数进行的扩展。应用对其虚拟地址空间的目前未出现的一部分进行访问。使用Linux的标准的依赖体系结构的和核心存储器管理函数来处理引起的页错误。与常规处理不同，该文件系统已安装了用于与目标页相关联的文件的filemap_xip_nopage处理器。此处理器使用get_xip_page检索该设备上的目标数据的引用。将此引用返回do_no_page函数，该函数在应用的虚拟地址空间页表内创建页表表项，以允许应用直接使用该设备上的数据而不需与操作系统的其它牵连。当文件映象被选择为是私有的时(标准机制应用)，页表表项稍后可经历写时拷贝机制。
因为应用二进制文件和共享库函数在Linux内经历文件映射，并且从而经历上述的页错误机制，所以实现了原地执行的效果。上述扩展保持Linux操作系统的与I/O相关的组件内的整个结构和层隔离不动：设备驱动器层将物理块号映射到设备，但是不对文件或其它逻辑对象起作用。文件系统执行逻辑文件和物理块号寻址之间的映射，但是不对设备的内部结构起作用。在另一方面，数据传输本身被倒转：当使用新扩展时设备驱动器不传输任何数据。在文件操作库函数中直接传输数据。此解决方法的优点包括对设备驱动器层和通用文件系统的非常小的并且仅仅是非插入的改变。任何通用文件系统可容易地受益于原地执行机制，例如减小的存储器消耗和增加的性能。