JP2006294028A - System for providing direct execution function, computer system, method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To disclose an operating system to implement a direct execution function. <P>SOLUTION: The operating system is the following new and creative functional component for implementing the direct execution function; a direct access interface of a file system between a memory/file manager and at least one file system driver, the direct access interface of the file system is the direct access interface of the file system which provides a function for retrieving a system memory address with content of a specific file in specific offset and a device direct access interface between at least one file system driver and at least one device driver which provides an access to at least one memory address specific device. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates generally to operating systems, and more particularly to operating systems that provide systems and methods for implementing direct execution functions.

  Prior art computer systems include non-volatile mass storage devices (eg, hard disk drives) for holding programs and data files. The contents of these files are loaded into RAM (“Random Access Memory”) type system memory and accessed or executed by the CPU (“Central Processing Unit”). This operation is generally performed by the operating system instead of the application program. Prior art computer systems and operating systems support virtual memory and demand paging. Instead of using the system memory address directly to indicate the code and data used by the application, the application uses a “virtual address” instead to indicate the storage location, which is implemented by the CPU circuit. And converted into a system memory address by a paging mechanism controlled by the operating system. As a result, the operating system can eliminate the need to load entire program and data files into RAM. Rather, the system memory is divided into specific sized chunks (called “pages”), and when the operating system accesses this particular page, it loads the corresponding chunk of file contents into each memory page. This process is usually referred to as “demand paging”.

  One disadvantage of this method is that the RAM needs to hold the contents of the program and data files, reducing the amount of RAM that can be used for other purposes. Furthermore, it is generally necessary to download the contents into the RAM depending on the situation. Thus, some prior art computer systems provide another type of non-volatile storage that can be accessed directly by the CPU, similar to RAM ("memory addressing device"). One prior art implementation of a memory addressing device is a flash memory card. Using a memory addressing device allows the CPU to directly execute code and access data stored on the memory addressing device without first downloading the contents into the RAM. This method of directly executing code residing on a memory addressing device is called “direct execution”. To provide direct execution capabilities for applications running on operating systems that support virtual memory, the operating system must ensure that a specific virtual address in the application's address space is within the range of addresses supported by the memory addressing device. It is necessary to control the paging mechanism so that it is mapped to the system memory address.

  Other prior art computer systems provide virtualization functions. Virtualization is implemented by software programs often called “hypervisors” that run a single computer system, but multiple “guest” operating systems each run simultaneously in separate “virtual machines” To be able to. Looking at each virtual machine from the operating system, it appears that the virtual machine itself is operating internally as an actual computer system with CPU, RAM and I / O devices. Access to these virtual components is intercepted by the hypervisor and translated into access to the actual components. Thereby, the resources of the computer system can be shared among a plurality of guest operating systems, and the utilization rate of the entire system resources can be increased.

  One disadvantage of some prior art virtualized computer systems is that the same program or data is accessed simultaneously by multiple guests operating under the same hypervisor, and each guest operating system In other words, it is necessary to separately assign virtual RAMs for holding the contents of the contents, and thus, it is necessary for the hypervisor to assign a plurality of the same copies of the contents to the physical RAMs. This means that there is a reduction in memory that can be used for other purposes, which limits the number of guests that can operate efficiently and simultaneously. Thus, some prior art hypervisors provide a segment of physical memory ("shared memory segment") that can be accessed simultaneously by multiple guests. By storing the program or data file in the shared memory segment, multiple guests can access the file simultaneously, eliminating the need to first download the contents into virtual RAM. When viewing the shared segment from the guest operating system, it appears as if it were a physical memory addressing device.

  Data and program files are generally stored on devices that use standard file system layouts, and depending on the operating system, multiple different file system layouts optimized for different usage scenarios can be used. In order to be able to do this, prior art operating systems are typically structured into multiple components. Depending on the operating system, there is a central file and memory management component, multiple file system drivers, and multiple I / O device drivers. Thus, the operating system is supported on any supported I / O device by using appropriate pairs of file system drivers and I / O device drivers in combination with file and memory management components. Make any file system layout available. However, prior art operating systems cannot access memory addressing devices in a form that allows direct execution using existing file system drivers. Direct execution supporting access to memory addressing devices is implemented in a monolithic form.

  In fact, some prior art operating system implementations cannot use standard file system layouts to store data on memory-addressed devices, but rather in a way that is specific to such devices, The data on these devices needs to be arranged. This arrangement has several disadvantages, especially for computer systems that use both I / O devices and memory addressing devices. Supporting different file system layouts can make system management even more difficult. Different tools are required to format, manage, backup and restore different layouts. It becomes even more difficult to migrate an existing set of files from an I / O device to a memory addressing device or vice versa. The particular layout required by the memory addressing device does not provide a standard file system layout for all existing features (eg, implementing access control and privilege checking).

  Another prior art implementation (XIP2FS file system for Linux (a trademark of Linus Torvalds in the United States and other countries, hereinafter the same)) on zSeries (trademark of IBM Corporation) is provided by the Linux operating system Program and data on a virtual memory addressing device (provided by the z / VM (IBM Corporation trademark) hypervisor) using a second extended file system ("ext2"), one of the standard file system formats Support for storage in shared memory segments). However, this method has most of the disadvantages described in the paragraph above, cannot use other standard Linux file system formats, and XIP2FS does not provide all the features of ext2. (For example, XIP2FS does not support write access).

  Another disadvantage of XIP2FS is that XIP2FS is not incorporated into the above component structure of the operating system, and if XIP2FS accesses a file using the ext2 file system layout, XIP2FS will not be able to use Linux ext2 Instead of accessing using a file system driver, instead re-implement the access logic necessary to access the ext2 file system layout. Again, XIP2FS does not support all the features of ext2 because only a portion of the complete ext2 logic is reimplemented. As yet another disadvantage, the standard ext2 file system component of the Linux operating system has been developed over time and new features have been added, for example, the version of the ext2 file system driver provided with the Linux kernel version 2.6 is Added support for faster access to very large directory structures and more sophisticated access control mechanisms. XIP2FS does not automatically benefit from such enhancements of the ext2 driver, but all necessary features need to be re-implemented in the XIP2FS code.

  An object of the present invention is to provide a method for solving the disadvantages of the prior art described above by providing a direct execution function by an operating system.

  The present invention discloses an operating system that provides a new system and method for implementing a direct execution function.

  A prior art operating system upon which the present invention is based includes a memory / file manager having an interface to an application program, at least one file system driver having a file system I / O interface to the memory / file manager, and a file system driver. At least one device driver having a device I / O interface to the at least one device driver, the at least one device driver having at least one I / O base device and a device I / O interface to the file system driver. Providing access to at least one device driver, wherein at least one device driver is associated with at least one memory addressing device. That provides access, operating system provides a direct execution function for accessing at least one memory addressing device.

Prior art operating systems have the following new and original functional components for implementing direct execution functions:
A file system direct access interface between the memory / file manager and at least one file system driver, wherein the file system direct access interface retrieves a system memory address of a file content at a specified offset. An interface that provides the ability to search and the file resides on a memory addressing device;
A device direct access interface between at least one file system driver and at least one device driver providing access to at least one memory addressing device, wherein the device direct access interface is at least one Extended with an interface that provides a function to search the system memory address of the specified block of the memory addressing device,
The direct execution function provides access to at least one memory addressed device by using a memory / file manager, at least one file system driver, a file system direct access interface and a device direct access interface. Provided by device drivers.

  The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.

  The novel features of the invention are set forth in the appended claims. However, the invention itself, and preferred modes of use, other objects and advantages, are best understood by referring to the following detailed description of specific embodiments and read in conjunction with the accompanying drawings. Let's go.

  FIG. 1 shows a block diagram of a computer system 10. Computer system 10 may be a personal computer, mainframe computer, or some other type of computer or data processing system. The computer system 10 may be a virtual machine provided by a hypervisor operating on another computer system, as described below. The computer system 10 includes a central processing unit (“CPU”) 11, a random-access memory (“RAM”) 12, a memory addressing device 13, and an I / O base device 14. In one embodiment, the memory addressing device 13 may be a flash memory card. In other embodiments, the memory addressing device 13 may be any device that the CPU 11 can directly access for memory operations. In one embodiment, the I / O base device 14 may be a hard disk drive. In other implementations, the I / O base device 14 may be any device that can copy data from or to the RAM 12 using I / O operations. Computer system 10 may also include multiple instances of memory addressing device 13 and / or I / O base device 14 or both. CPU 11, RAM 12, and devices 13 and 14 are coupled to system bus 15. CPU 11 can directly access RAM 12 and memory addressing device 13 for memory operations. The CPU 11 cannot directly access the I / O base device 14 for memory operations, but data can be copied from the device 14 to the RAM 12 or vice versa using I / O operations. The computer system 10 executes an operating system capable of executing one or more application programs (described in detail below). The operating system manages and coordinates access by application programs to various resources of the computer system 10 (CPU 11, RAM 12, devices 13 and 14).

  In some implementations, the computer system 10 may be a virtual machine emulated by a hypervisor running on another computer system. FIG. 2 shows one embodiment in which the computer system 10 comprises a virtual CPU 11, a virtual RAM 12, and virtual devices 13 and 14. All virtual components are provided by a hypervisor 21, which is a software program that runs on another computer system 20, and itself consists of a CPU, RAM and devices. The hypervisor 21 provides the virtual components 10-14, either entirely by software or by using visualization hardware assistance functions provided by the computer system 20. In addition to the virtual machine 10, another virtual machine 22 operates simultaneously under the hypervisor 21 on the computer system 20. In one embodiment, the hypervisor 21 is IBM Corp. Z / VM (a trademark of IBM Corporation) software program manufactured and sold by IBM Corporation, which may be a program that runs on an IBM MeServer (a trademark of IBM Corporation) zSeries (a trademark of IBM Corporation) mainframe computer. In this embodiment, computer system 10 may be a virtual machine provided by z / VM and memory addressing device 13 may be a non-contiguous storage segment (“DCSS”) defined based on z / VM). . DCSS is a segment of memory managed by z / VM that can be used simultaneously by multiple virtual machines. z / VM holds only one copy of the contents of the DCSS in the real RAM of the computer system 20, even if multiple virtual machines can use the DCSS simultaneously.

  All the components that the CPU 11 can directly access for memory operation constitute a system memory address space 30 of the computer system 10, as shown in FIG. RAM 12 and memory addressing device 13 are part of system memory address space 30. In addition, other components (not shown) are system memory address space 30, such as read only memory ("ROM") or video card frame buffer. All program instructions executed by the CPU 11 and all memory data accessed by instructions executed by the CPU 11 must be present in the system memory address space 30 at the time of execution. To increase the apparent size of available memory and prevent different application programs running simultaneously on the same computer system from accidentally modifying each other's memory, the operating system Provides a “virtual address space” and provides access to selected portions of the system memory address space within the virtual address space. The CPU 11 executes the application code, but can access only the memory existing in the virtual address space of the application. Both the virtual address space and the system memory address space are divided into equal-sized chunks commonly referred to as “pages” so that they can be converted between the virtual address space and the system memory address space.

  FIG. 3 shows the system memory address space 30 of the computer system 10. Further, a virtual address space 31 of the application program is shown. For each page that can be addressed in the virtual address space 31, there must be a page descriptor that actually describes the state of the page. The page may or may not exist in the system memory address space 30 at some point. If the page exists in the system memory address space 30, the page descriptor will indicate that fact and will indicate the location of the page in the system memory address space 30. If the page does not exist in the system memory address space 30, the descriptor indicates that fact and provides additional information that allows the operating system to determine the location of the content that the application program is trying to access through this page. Will be included. A set of all page descriptors for the virtual address space is called a page table. The virtual address space page table is maintained by the operating system.

  While the CPU 11 is executing application code in the virtual address space 31, all memory addresses accessed by the CPU 11 are systematized from the virtual addresses in the virtual address space 31 using the page table for the virtual address space 31. It is converted into a system memory address in the memory address space 30. This conversion is performed by a paging mechanism, which may be a hardware or software implementation, or a combination thereof. In some embodiments, the paging mechanism is implemented by a paging unit that resides in the CPU 11. When the CPU 11 accesses a page in the virtual address space 31 that does not currently have a page corresponding to the system memory address space 30, the paging mechanism causes the CPU 11 to generate a page fault interrupt. This interrupt causes operating system code called a “page fault handler” to bring the required content into several pages in the system memory address space 30 and update the page table to place the virtual page in the system memory address space 30. Map to this page in The application then continues to execute and access the page. This process is commonly referred to as “demand paging”.

  In the situation of the embodiment shown in FIG. 3, the virtual address space 31 currently holds four pages. Three pages (32a-32c) contain application code that is currently being executed, and one page (32d) contains data accessed by the application. Application code contained in pages 32a-32c is loaded from application program files residing on I / O base device 14 in blocks 34a-34c. Application code pages 32a and 32b are actually present in system memory address space 30 and are present in pages 33a and 33b of RAM 12. Similarly, the data page 32d exists in the system memory address space and exists in the page 33d of the RAM 12. Application code page 32 c currently does not exist in system memory address space 30. When the application accesses page 32c, the operating system page fault handler allocates a new page 33c (not shown) in RAM 12, performs an I / O operation, copies the contents of block 34c to page 33c, and stores the page table. Update to map page 32 c of virtual address space 31 to page 33 c of system memory address space 30. For pages 32a and 32b, this process is already complete at the time shown in FIG. The data pages 32d / 33d hold the contents generated at the time of execution by the application. This content is not loaded from the I / O base device 14.

  As shown in FIG. 3, when the CPU 11 is executing an application program that exists on the I / O base device 14, the page of the RAM 12 needs to hold the code of the application program being executed. However, if the application program resides on a memory addressing device, this is not necessary and more pages of RAM 12 can be used for other purposes (or alternatively, less RAM is intended as a whole). Task can be performed). This process is commonly referred to as “direct execution”. FIG. 4 shows the same application running in virtual address space 31 as in FIG. 3, but in this case the application resides on the memory addressing device and not directly on the I / O base device 14. . As shown in FIG. 4, application code from the application program file is present in blocks 35 a-c of the memory addressing device 13. Since the memory addressing device 13 exists in the system memory address space 30, the blocks 35a and 35b are directly mapped to the pages 32a and 32b of the virtual address space 31, respectively. Similarly, when an application accesses page 32c, the operating system page fault handler simply establishes another mapping between page 32c of virtual address space 31 and page 35c of system memory address space 30, and the operating system Need not allocate any page to the RAM 12. On the other hand, it is noted that the data page 32d is mapped to the page 33d of the RAM 12 as in the scenario shown in FIG.

  FIG. 5 visualizes the component structure of a prior art operating system 40 that does not embody the present invention. Only the components necessary to implement the demand paging and direct execution functions shown in FIGS. 3 and 4 are illustrated. The operating system 40 includes a memory / file manager 41 that processes access requests to files residing on the I / O base device 14 or the memory addressing device 13 that are issued from an application program 49 via an interface 48. In order to access files on the I / O base device 14, the memory / file manager 41 interacts with the file system driver 43 via the file system I / O interface 45. The operating system 40 includes multiple versions of file system drivers, each file system driver responsible for processing a particular file system type, and all file system drivers implement the same file system I / O interface 45. . Similarly, the operating system 40 includes multiple versions of device drivers, each device driver responsible for processing a specific type of device, and all device drivers implement the same device I / O interface 46.

  As shown in FIG. 5, in the component structure of the operating system 40, the device driver 44 (and all device drivers) is responsible for transferring data from a specified location on the I / O base device into RAM. Or vice versa. A device driver has no knowledge of the contents of the device or how these contents are organized. The data present on the device is generally divided into blocks called “blocks”, each identified by a “number of blocks”. The device I / O interface 46 makes it possible to copy data from the block identified by the block number B to the block of the RAM starting at the address A, or vice versa, at the request of the device driver.

  The operating system 40 provides file system drivers so that data can be stored on the device in structured storage. The file system driver allows access to data stored on the device as a collection of “files”, each file providing an abstraction of an ordered sequence of bytes. All files are identified by several means provided by a file system commonly referred to as a “file name”. The file system keeps track of which bytes of each file are stored in which blocks of the underlying device. Information required to perform this record keeping is usually called “file system metadata” and is stored on the underlying device. The specific layout of file system metadata varies from file system to file system. As shown in FIG. 5, within the component structure of the operating system 40, it is the file system driver 43 (and all file system drivers) that implements all the logic necessary to process the layout of the file system metadata. Is responsible. The file system I / O interface 45 starts the data from the file F identified by a certain file name in the block of RAM starting at the specified offset 0 in the file F and starting at the address A, or vice versa. Recognize file system driver requests to copy. To handle such a request, the file system driver examines the file system metadata to determine which block B of the underlying device holds the data corresponding to offset 0 in file F. The device driver device I / O interface 46 that processes the underlying device is used to determine whether to copy between the device and the specified block of memory.

  Thus, as shown in FIG. 5, within the component structure of the operating system 40, the demand paging function shown in FIG. 3 is implemented as follows: the application is on a page that is not currently used in the system memory address space. When accessed, the operating system page fault handler (usually part of the memory / file manager 41) determines from the page descriptor what content the application is looking for in the page. The page descriptor identifies the content by specifying file F and offset 0 in file F where the content is found. Next, the memory / file manager 41 allocates a new page to the RAM 12 and copies the data from the file system driver 43 through the file system I / O interface 45 to the new page from the offset 0 in the file F. To request. As described above, the file system driver 43 examines the file system metadata to determine which block B of the underlying device (in this case, the I / O base device 14) holds the data, and Using the device I / O interface 46 of the driver 44, the data is copied to the new page. When the I / O operation is completed, the memory / file manager 41 updates the page table accordingly.

  However, since the prior art file system I / O interface 45 is not suitable for this purpose, it is not possible to use the file system driver 43 to perform direct execution access to files that reside on the memory addressing device 13. Impossible. Instead, as shown in FIG. 5, within the component structure of the operating system 40, direct execution accesses are handled by the XIP manager 42, which is tightly embedded in the memory / file manager 41, and the memory addressing device 13 Direct access to Thus, the XIP manager 42 is responsible for both accessing the memory addressing device 13 and processing the file system layout of the data stored on the device. Accessing data on the memory addressing device 13 using a file system layout other than the file system layout supported by the XIP manager 42 means that the operating system 40 would otherwise file in such a file system. Even if you think to provide a system driver, it is not possible.

  The present invention removes such constraints. FIG. 6 illustrates the component structure of the operating system 50 that implements direct execution access to the memory addressing device 13 embodying the present invention. Compared to the prior art operating system 40 shown in FIG. 5, the operating system 50 provides the same interface to all hardware components of the computer system 10 (RAM 12, I / O base device 14, memory addressing device 13). Hold. The operating system 50 uses the same interface 48 for the application program 49. The memory / file manager 51 is a modified version of the memory / file manager 41 provided by the prior art (see FIG. 5), and the file system driver 52 is a modified version of the file provided by the prior art (see FIG. 5). This is a system driver 43. The operating system 50 also provides a device driver 53 that accesses the memory addressing device 13. Some prior art versions of the operating system 40 have also provided device drivers that access the memory addressing device 13 as well, but such drivers only include the device I / O interface 46 (see FIG. 5). Note that it was not possible to implement direct execution and thus provide direct execution functionality. This function was implemented by the XIP manager 42, but the XIP manager 42 directly accesses the memory addressing device 13 without using a device driver. As shown in FIG. 6, the present invention does not require XIP manager components. Instead, the direct execution function is in this case incorporated in the memory / file manager 51, the file system driver 52 and the device driver 53. This is possible by using two new interfaces: a file system direct access interface 54 provided by the file system driver 52 and a device direct access interface 55 provided by the device driver 53. A basic feature of the device direct access interface 55 is that it provides a means for retrieving the system memory address A of block B of the memory addressing device that exists in the system memory address space. Similarly, a basic feature of the file system direct access interface 54 is that the system memory address of the contents of file F at offset 0 if file F exists on a memory addressing device that exists in the system memory address space. To provide a means for searching for A. The use of these direct access interfaces will be described in detail below.

  As shown in FIG. 6, the operating system 50 interacts with an application program 49 through an interface 48. Part of interface 48 consists of demand paging requests triggered by application program 49, which accesses a page in virtual address space 31 that is not currently mapped to a page in system memory address space 30. (Note that the virtual address space 31 and the system memory address space 30 are shown in FIGS. 3 and 4, and the virtual address space 31 corresponds to the virtual address space of the application 49.) A request (“system call”) to the operating system 50 by the application program 49 to read, write, or otherwise access the contents of a file residing on the I / O base device 14 or the memory addressing device 13 Consisting of requests to do. The memory / file manager 51 is a component of the operating system 50 that processes requests from the application program 49 via the interface 48. To access the contents of a file residing on the I / O base device 14 or the memory addressing device 13, the memory / file manager 51 has a file system I / O interface 45 or a file system direct access interface 54 or both. To interact with the file system driver 52. The operating system 50 includes multiple versions of file system drivers, each responsible for processing a particular file system layout. All file system drivers implement the same file system I / O interface 45, and some file system drivers are also suitable for performing direct execution access to files residing on a memory addressing device. A direct access interface 54 is implemented. File system driver 52 interacts with device drivers 44 and 53 via device I / O interface 46 and / or device direct access interface 55. The operating system 50 also includes multiple versions of device drivers, each responsible for processing a specific type of device. All device drivers implement the same device I / O interface 46, and the device driver of the memory addressing device 13 is further suitable for performing direct execution access to files residing on the memory addressing device 13. An access interface 55 is implemented. In the case of a file system driver that provides both an I / O interface 45 and a direct access interface 54, the memory / file manager 51 provides both periodic access and direct execution access to files processed by such file system driver. Can be performed. FIGS. 7 and 8 detail the control flow required to perform periodic access and direct execution access, respectively. FIG. 9 details the decision logic required to select which of the two methods is used to access a particular file.

  FIG. 7 shows a control flow when the operating system 50 processes a request to access a file existing on the I / O base device 14. Note that this control flow is the same as the control flow used by the prior art operating system 40 for the corresponding access. The steps of the control flow are expressed in order by actions 60a-f. The particular action shown here corresponds to the situation shown in FIG. 3 after the application 49 attempts to access the page 32c of the virtual address space 31. Since this page is not currently mapped to any page in system memory address space 30, a page fault interrupt is generated and handled by the memory / file manager 51 component of operating system 50. This is represented by action 60a in FIG. The memory / file manager 51 reads from the page descriptor of page 32c that the application expects the contents of page 32c to correspond to the contents of file F at offset 0. The memory / file manager 51 determines that the file F exists on the file system processed by the file system driver 52. The memory / file manager 51 further determines that file F does not support direct execution (this will be described in detail below). Next, the memory / file manager 51 allocates a free page 33c in the RAM 13, determines its system memory address A, and passes the file F at the offset 0 through the file system I / O interface 45 of the file system driver 52. Requests that the contents be copied to the page at system memory address A (action 60b). The file system driver 52 determines that the data of the file F at the offset 0 exists on the block B of the I / O base device 14 and that the device driver 44 is responsible for accessing the I / O base device 14. The file system driver 52 then requests to copy the block B of the I / O base device 14 to the page at system memory address A via the device I / O interface 46 of the device driver 44 (action 60c). . The device driver 44 causes the I / O operation 61 on the I / O base device 44 to execute the copy. When the I / O operation 61 is completed, the device driver 44 reports the completion to the file system driver 52 via the device I / O interface 46 (action 60d), and the file system driver 52 similarly receives the file system I The completion is reported to the memory / file manager 51 via the / O interface 45 (action 60e). The memory / file manager 51 finally establishes a mapping of the page 32 c of the virtual address space 31 to the page 33 c in the system memory address space 30.

  FIG. 8 similarly shows a control flow when the operating system 50 processes a request to perform a direct execution access to a file residing on the memory addressing device 13. Note that this flow uses the new direct access interface described by the present invention, unlike the flow used by the prior art operating system 40 for corresponding access. Further, some accesses to files on the memory addressing device 13 are not suitable for direct execution access, in which case a control flow equivalent to the control flow shown in FIG. 7 and described above is used instead. Thus, periodic I / O access to the file is executed. This is possible because the device driver 53 implements the device I / O interface 46 as well as the device driver 44.

  The steps of the control flow shown in FIG. 8 are expressed by actions 70a to 70f in order. The specific action shown in FIG. 8 corresponds to the situation shown in FIG. 4 after the application 49 attempts to access a page in the virtual address space 31. As shown in FIG. 7, a page fault interrupt is generated and processed by the memory / file manager 51 (action 70a), and the memory / file manager 51 again uses the page descriptor of the page 32c, and the application Read that the content is expected to correspond to the content of file F at offset 0. The memory / file manager 51 determines that the file F exists on the file system processed by the file system driver 52. The memory / file manager 51 further determines that file F does not support direct execution (this will be described in detail below). The memory / file manager 51 then requests to retrieve the system memory address of the contents of the file F at offset 0 via the file system direct access interface of the file system driver 52 (action 70b). The file system driver 52 determines that the content of the file F at the offset 0 exists on the block B of the memory addressing device 13 and that the device driver 53 is responsible for accessing the memory addressing device 13. The file system driver 52 then requests to retrieve the system memory address of block B of the memory addressing device 13 via the device direct access interface 55 of the device driver 53 (action 70c). The device driver 53 returns the address A to the file system driver 52 via the device direct access interface 55, with the block B of the memory addressing device 13 corresponding to the page 35c of the system memory address space 30 (action 70d). Similarly, it is determined that the address A is returned to the memory / file manager 51 through the direct access interface 54 of the file system (action 70e). The memory / file manager 51 finally establishes a mapping of the page 32c of the virtual address space 31 to the page 35c at the address A of the system memory address space 30.

  FIG. 9 shows the control flow within the operating system 50 (FIG. 6) when deciding whether to access the file F using the file system I / O interface or the file system direct access interface. The operating system first determines which file system driver is responsible for the file system FS that holds the file F. If the file system driver does not support any direct access interface of the file system, the file system I / O interface is used. Otherwise, the operating system determines which device driver is responsible for the device D under the file system FS. If the device driver does not support any device direct access interface, the file system I / O interface is used as well. Otherwise, the operating system determines whether the file system FS has been configured by the user for direct execution access to the file F. If configured, the file system direct access interface is used, otherwise the file system I / O interface is used. In some implementations, the user only chooses whether to allow direct execution access to all files on the FS or to prevent direct execution access to all files on the FS. In other embodiments, the user makes such a selection separately for each single file. Further, in some implementations, direct execution access can be allowed only when other configurable file system parameters are set by the user to values compatible with direct execution, for example, file The system block size needs to be configured to be equal to the size of a plurality of system memory pages or the size of a plurality of system memory pages.

  Note that the operating system does not necessarily have to execute the complete decision logic shown in FIG. Instead, the selection is selected when file F is first accessed and stored in the operating system data structure associated with file F, and subsequent accesses are stored in the data structure. Reuse decision results.

10-18 illustrate in more detail one embodiment of the present invention within the Linux operating system. The present invention extends the interface to incorporate direct execution functionality within the I / O component structure of the standard operating system, not to replace the entire component structure. Linux provides the following component layers in connection with performing I / O operations:
A device driver layer that allows access to an external storage device without recognizing the specific hardware involved;
A file system layer that can access the external storage device using a view of the logic file without recognizing the external storage device;
A memory management layer that allows applications to run without being aware of virtual memory and the dynamic address translation technology used by the operating system.

  FIG. 10 illustrates the device abstraction implemented in many modern operating systems. This embodiment shows a Linux device driver. The make_request function is called to submit a request to read or write data to the device. The request_queue and do_request functions are part of the Linux internal optimization. The device driver operates in a loop of “dispatch request-> process request-> interrupt handler-> dispatch request”, and all work submitted to the device driver is executed.

  The device driver layer allows submitting read requests or write requests. Frequent users of this layer are file system readpage (s) / writepage (s) operations that transfer data from or to a file. The physical block number is used to address the data.

  The present invention provides an extension to the device driver layer interface shown in FIG. This extension provides functionality that can be used to directly reference the data on the device while keeping the existing interface intact. This reference can be used to access data on the device without submitting a request and wait for it to complete. This extension can optionally be implemented by a device driver that accesses the memory addressing device. The new operation direct_access gets a physical block number similar to make_request, but does not transfer any data. Instead, a data reference is returned. This reference can be used to read or write any data to the physical block at any time thereafter until the device is closed / unmounted again without further interaction with the device driver layer. The use of a new interface is optional, and the traditional make_request interface maintains the original state for users who do not support the new interface, such as raw device drivers. It is important for a conventional interface to support a general-purpose file system, and the file system metadata is transferred using the general-purpose file system (inode, directory entry, etc.).

  FIG. 12 shows how the generic file system in Linux uses the device driver's make_request function to implement address space operations. The read page (s) / write page (s) function uses the get_block function [repeated when processing multiple pages] to identify the number of physical blocks on the device associated with multiple target pages. The make_request function shown in FIG. 10 is used to access data. In Linux, the file system typically uses address space operations along with file system library functions to perform file operations such as sys_read () and sys_write (). The use of these address space operations and library functions is optional, but most general purpose file systems use them. Address space operations, read page (), read pages (), write page (), and write pages () are used to read or write one or more memory pages of data from a device driver. The Logic file handles and offsets are used to address memory pages. This addressing is converted into a physical block number by the file system.

  The present invention provides an extension to the address space manipulation interface with a function named get_xip_page that allows a storage device reference to be searched behind a memory page, as shown in FIG. This function uses the file handle and addressing offset, and converts the file handle and addressing offset into a physical block number by calling the get_block function, and behind the physical block, the device driver layer A storage device reference is retrieved from the direct_access function (shown in FIG. 11). This reference can be used to read or write any data to the physical block at any time thereafter, without further interaction with the file system or device driver layer, until the file is truncated or the file system is unmounted. Use of the new interface is mandatory if supported, and the legacy read page (s) / write page (s) interface or the new get_xip_page interface is supported for files in terms of data integrity .

  The main user of the read page (s) / write page (s) function is a file system library function. FIG. 14 shows how a file system library function performs a read_type file operation for a Linux general purpose file system.

  The generic_file_read function performs file operations associated with the sys_read () system call.

  The generic_file_readv function performs file operations associated with the sys_readv () system call.

  The generic_file_aio_read function performs a read operation associated with an asynchronous IO system call.

  The generic_file_sendfile file operation performs a file operation associated with the sys_sendfile () system call.

  All these functions call generic_mapping_read, which uses the read page (s) function (as shown in FIG. 12) to read one or more pages from the device. The use of these functions is optional for the file system, but the generic file system uses all functions instead of implementing its own file manipulation implementation.

  FIG. 16 illustrates how a file system library function performs a write type file operation for a Linux general purpose file system.

  The generic_file_write function performs file operations associated with the sys_write () system call.

  The generic_file_writeev function performs file operations associated with the sys_writeev () system call.

  The generic_file_aio_write function performs a write operation associated with an asynchronous IO system call.

  All these functions call generic_file_direct_write (if the target file is opened using the optional O_DIRECT), or generic_file_buffered_write. These functions use the write page (s) function to write one or more pages to the device.

  The present invention provides an extension of the library function to allow the library function to use the get_xip_page interface if it is supported. FIG. 15 illustrates the extensions that are made to the file system library functions for read type operations. Depending on whether there is a get_xip_page address space operation, the operation is performed using the generic_mapping_read function or the new do_xip_mapping_read function to perform the operation. The do_xip_mapping_read function uses a get_xip_page address space operation to retrieve a reference to the target data on the device. For data transfer, this reference is used directly and there is no need to perform I / O operations. FIG. 17 shows the extensions that are made to the file system library functions for a write type operation. Depending on whether there is a get_xip_page address space operation, perform the operation using the generic_file_buffered_write / generic_file_buffered_write function or the new generic_file_xip_write function. The generic_file_xip_write function uses a get_xip_page address space operation to retrieve a reference to the target data on the device. For data transfer, this reference need not be used directly to perform I / O operations.

  All file systems that implement get_xip_page address space operations do not require any further code changes to perform direct execution access using all file operations implemented by library functions. FIGS. 15, 17 and 18 illustrate how the extended library functions implement their respective functions depending on whether get_xip_page address space operations are implemented. When get_xip_page is implemented, all library functions directly perform all data transfers to the storage device using references retrieved from get_xip_page. FIG. 18 shows the extensions made to the file system library functions for file memory mapping. This application accessed a portion of the virtual memory address space that does not currently exist. The standard architecture dependency and core memory management functions of Linux are used to handle the resulting page fault. Unlike regular processing, the file system has installed a filemap_xip_nopage handler for the file associated with the target page. This handler uses get_xip_page to retrieve a reference to the target data on the device. This reference is returned to the do_no_page function to create a page table entry in the application's virtual address space page table, allowing the application to directly use the data on the device without further involvement of the operating system. The page table entries are later copied on the writing mechanism if the file mapping is selected to be private (the standard mechanism applies).

  The effect of direct execution is achieved because the binary file and shared library of the application are subject to Linux file mapping, and as a result, subject to the page fault mechanism described above.

  The above extensions maintain the overall structure and layer isolation in the I / O related components of the Linux operating system. The device driver layer maps physical block numbers to devices but does not work with files or other logic objects. The file system performs the mapping between the logic file and the physical block number addressing, but does not work with the device structure. On the other hand, the data transfer itself is reversed upside down. The device driver does not transfer data when using a new extension. Data is directly transferred by file operation library functions. The effect of this solution is to include only very small and non-intrusive changes to the device driver layer and the generic file system. A general purpose file system can easily obtain the advantages of a direct mechanism, such as reduced memory consumption and increased execution.

FIG. 2 shows a block diagram of a computer system necessary to implement the present invention. 2 illustrates a virtual machine environment hosting the computer system shown in FIG. 1 as a guest of some embodiments of the present invention. 2 illustrates virtual memory and demand paging functionality provided by prior art operating systems. Fig. 4 illustrates a direct execution function provided by a prior art operating system. Fig. 2 shows the component structure of a prior art operating system that implements direct execution. Fig. 4 illustrates the component structure of an operating system that implements direct execution using the present invention. FIG. 7 illustrates a control flow through the components of the operating system of FIG. 6 used to access an I / O based device according to the present invention. FIG. 7 illustrates a control flow through the components of the operating system of FIG. 6 used to perform direct execution access to a memory addressing device according to the present invention. FIG. 9 illustrates decision logic by the operating system of FIG. 6 used to select which of the two control flows shown in FIGS. 7 and 8 to use. Fig. 4 illustrates an abstraction of a device implemented in a prior art Linux operating system. Fig. 5 illustrates extensions made to the device driver layer within the Linux operating system that implements the present invention. Fig. 4 illustrates how a universal file system provides address space operations for reading and writing one or more pages to devices in prior art Linux operating systems. Fig. 4 illustrates extensions made to file system address space operations within a Linux operating system implementing the present invention. The file system library functions show how to perform read type file operations on a general purpose file system in a prior art Linux operating system. Fig. 6 illustrates extensions made to file system library functions for read type operations within the Linux operating system implementing the present invention. FIG. 4 illustrates how a file system library function performs a write type file operation for a general purpose file system within a prior art Linux operating system. Fig. 4 illustrates extensions made to file system library functions for write type operations within a Linux operating system implementing the present invention. Fig. 4 illustrates extensions made to file system library functions for file memory mapping in a Linux operating system implementing the present invention.

Explanation of symbols

12 RAM
13 Memory Addressing Device 14 I / O Base Device 44, 53 Device Driver 49 Application Program 50 Operating System 51 Memory / File Manager 52 File System Driver

Claims (10)

A memory / file manager (51) having an interface (48) to the application program (49);
At least one file system driver (52) having a file system I / O interface (45) to the memory / file manager (51);
At least one device driver (44) having a device I / O interface (46) to the file system driver (52), wherein the at least one device driver (44) is at least one I / O. A device driver (44) that provides access to the base device (14);
At least one device driver (53) having a device I / O interface (46) to the file system driver (52), wherein the at least one device driver (53) includes at least one memory addressing; A device driver (53) that provides access to the device (13);
An operating system (50) provides a direct execution function for accessing at least one memory addressing device (13), the system comprising:
A file system direct access interface (54) between the memory / file manager (51) and the at least one file system driver (52), wherein the designated file is on the memory addressing device (13). A file system direct access interface (54) that provides a function to retrieve a system memory address of the contents of the file at a specified offset,
A device direct access interface (55) between the at least one file system driver (52) and the at least one device driver (53) and providing access to the at least one memory addressing device (13) And a device direct access interface (55) providing a function for retrieving a system memory address of a designated block of at least one memory addressing device (13),
The direct execution function uses the direct access interface (54) and the device direct access interface (55) of the file system, so that the memory / file manager (51) and the at least one file system driver (52 ), And a system provided by at least one device driver (53) that provides access to the at least one memory addressing device (13).   The system of claim 1, wherein the system is part of or provided by the operating system.   The memory / file manager (51) accesses a file managed by the file system driver (52) using the file system direct access interface (54) or the file system I / O interface (45). The system of claim 1, wherein:   The file system driver (52) implements a direct access interface (54) of the file system by retrieving the system memory address of the contents of the specified file at a specified offset, and the contents are stored in the memory addressing device ( 13) by the device driver by using the device direct access interface that exists on a particular block and access to the block is provided by the device driver to retrieve the system memory address of the block The system of claim 1, provided.   The memory / file manager (51) implements direct execution access to a specified file at a specified offset, the file exists on a file system processed by the file system driver (52), and the file system is in memory By using the file system direct access interface (54) residing on the addressing device (13) and provided by the file system driver (52), the system memory address of the contents of the file at the offset is determined. The system of claim 1, wherein the content is directly executed by searching and using the address.   A computer system comprising the system according to claim 1.   The computer system according to claim 6, comprising a hypervisor that controls one or more virtual machines, wherein at least one virtual machine operates the system according to claim 1. .   The computer system according to any one of the preceding claims, wherein the memory addressing device (13) is embodied by a shared memory segment provided by the hypervisor to one or more of the virtual machines. A method for automatically providing a direct execution function by the system according to claim 1, wherein the system accepts a request for accessing a file by an application program and accesses the file. Determining whether to use a direct execution function for the method,
Determining a file system holding the file;
Determining whether a file system driver (52) managing the file system provides a direct access interface (54) for the file system;
Not using direct execution if the file system driver (52) does not provide a direct access interface (54) for the file system;
If the file system driver provides a direct access interface (54) for the file system, determining a device on which the file resides;
A device driver (53) managing the device (13) determining whether to provide the device direct access interface (55);
Not using direct execution if the device driver does not provide the device direct access interface (55);
Determining whether the file system is configured to allow direct execution functionality;
Providing direct execution functionality using the file system direct access interface (55).   A computer program stored in an internal memory of a digital computer, comprising a portion of software code for performing the method according to claim 9 when the program runs on a computer.

Images