summaryrefslogtreecommitdiff
path: root/Documentation/filesystems
diff options
context:
space:
mode:
authorNicolas Pitre <nicolas.pitre@linaro.org>2017-10-12 02:16:12 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2017-10-15 00:47:22 -0400
commiteddcd97659e31f59fc99c6c3ca3dcce403585f7e (patch)
tree50d7e8935e1aeebac0bbae1e5c9f6e9c671c5a3c /Documentation/filesystems
parentfd4f6f2a78aeaebb7094c1bb9b30623d18a86e4c (diff)
cramfs: add mmap support
When cramfs in physical memory is used then we have the opportunity to map files directly from ROM, directly into user space, saving on RAM usage. This gives us Execute-In-Place (XIP) support. For a file to be mmap()-able, the map area has to correspond to a range of uncompressed and contiguous blocks, and in the MMU case it also has to be page aligned. A version of mkcramfs with appropriate support is necessary to create such a filesystem image. In the MMU case it may happen for a vma structure to extend beyond the actual file size. This is notably the case in binfmt_elf.c:elf_map(). Or the file's last block is shared with other files and cannot be mapped as is. Rather than refusing to mmap it, we do a "mixed" map and let the regular fault handler populate the unmapped area with RAM-backed pages. In practice the unmapped area is seldom accessed so page faults might never occur before this area is discarded. In the non-MMU case it is the get_unmapped_area method that is responsible for providing the address where the actual data can be found. No mapping is necessary of course. Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Documentation/filesystems')
0 files changed, 0 insertions, 0 deletions