|  | Execute-in-place for file mappings | 
|  | ---------------------------------- | 
|  |  | 
|  | Motivation | 
|  | ---------- | 
|  | File mappings are performed by mapping page cache pages to userspace. In | 
|  | addition, read&write type file operations also transfer data from/to the page | 
|  | cache. | 
|  |  | 
|  | For memory backed storage devices that use the block device interface, the page | 
|  | cache pages are in fact copies of the original storage. Various approaches | 
|  | exist to work around the need for an extra copy. The ramdisk driver for example | 
|  | does read the data into the page cache, keeps a reference, and discards the | 
|  | original data behind later on. | 
|  |  | 
|  | Execute-in-place solves this issue the other way around: instead of keeping | 
|  | data in the page cache, the need to have a page cache copy is eliminated | 
|  | completely. With execute-in-place, read&write type operations are performed | 
|  | directly from/to the memory backed storage device. For file mappings, the | 
|  | storage device itself is mapped directly into userspace. | 
|  |  | 
|  | This implementation was initially written for shared memory segments between | 
|  | different virtual machines on s390 hardware to allow multiple machines to | 
|  | share the same binaries and libraries. | 
|  |  | 
|  | Implementation | 
|  | -------------- | 
|  | Execute-in-place is implemented in three steps: block device operation, | 
|  | address space operation, and file operations. | 
|  |  | 
|  | A block device operation named direct_access is used to retrieve a | 
|  | reference (pointer) to a block on-disk. The reference is supposed to be | 
|  | cpu-addressable, physical address and remain valid until the release operation | 
|  | is performed. A struct block_device reference is used to address the device, | 
|  | and a sector_t argument is used to identify the individual block. As an | 
|  | alternative, memory technology devices can be used for this. | 
|  |  | 
|  | The block device operation is optional, these block devices support it as of | 
|  | today: | 
|  | - dcssblk: s390 dcss block device driver | 
|  |  | 
|  | An address space operation named get_xip_mem is used to retrieve references | 
|  | to a page frame number and a kernel address. To obtain these values a reference | 
|  | to an address_space is provided. This function assigns values to the kmem and | 
|  | pfn parameters. The third argument indicates whether the function should allocate | 
|  | blocks if needed. | 
|  |  | 
|  | This address space operation is mutually exclusive with readpage&writepage that | 
|  | do page cache read/write operations. | 
|  | The following filesystems support it as of today: | 
|  | - ext2: the second extended filesystem, see Documentation/filesystems/ext2.txt | 
|  |  | 
|  | A set of file operations that do utilize get_xip_page can be found in | 
|  | mm/filemap_xip.c . The following file operation implementations are provided: | 
|  | - aio_read/aio_write | 
|  | - readv/writev | 
|  | - sendfile | 
|  |  | 
|  | The generic file operations do_sync_read/do_sync_write can be used to implement | 
|  | classic synchronous IO calls. | 
|  |  | 
|  | Shortcomings | 
|  | ------------ | 
|  | This implementation is limited to storage devices that are cpu addressable at | 
|  | all times (no highmem or such). It works well on rom/ram, but enhancements are | 
|  | needed to make it work with flash in read+write mode. | 
|  | Putting the Linux kernel and/or its modules on a xip filesystem does not mean | 
|  | they are not copied. |