mirror of
https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git
synced 2025-09-06 08:18:05 -04:00
Fixed MTP to work with TWRP
This commit is contained in:
commit
f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
68
Documentation/filesystems/xip.txt
Normal file
68
Documentation/filesystems/xip.txt
Normal file
|
@ -0,0 +1,68 @@
|
|||
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.
|
Loading…
Add table
Add a link
Reference in a new issue