summaryrefslogtreecommitdiffstats
path: root/Documentation/nommu-mmap.txt
diff options
context:
space:
mode:
authorChristoph Hellwig <hch@lst.de>2015-01-14 10:42:32 +0100
committerJens Axboe <axboe@fb.com>2015-01-20 14:02:58 -0700
commitb4caecd48005fbed3949dde6c1cb233142fd69e9 (patch)
tree1fdd9b7c15568c79eb3c1ed84a39858ddbcbc88b /Documentation/nommu-mmap.txt
parent97b713ba3ebaa6c8d84c2c720f5468a7c6a6eb4e (diff)
downloadlinux-stable-b4caecd48005fbed3949dde6c1cb233142fd69e9.tar.gz
linux-stable-b4caecd48005fbed3949dde6c1cb233142fd69e9.tar.bz2
linux-stable-b4caecd48005fbed3949dde6c1cb233142fd69e9.zip
fs: introduce f_op->mmap_capabilities for nommu mmap support
Since "BDI: Provide backing device capability information [try #3]" the backing_dev_info structure also provides flags for the kind of mmap operation available in a nommu environment, which is entirely unrelated to it's original purpose. Introduce a new nommu-only file operation to provide this information to the nommu mmap code instead. Splitting this from the backing_dev_info structure allows to remove lots of backing_dev_info instance that aren't otherwise needed, and entirely gets rid of the concept of providing a backing_dev_info for a character device. It also removes the need for the mtd_inodefs filesystem. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Tejun Heo <tj@kernel.org> Acked-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Jens Axboe <axboe@fb.com>
Diffstat (limited to 'Documentation/nommu-mmap.txt')
-rw-r--r--Documentation/nommu-mmap.txt8
1 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
index 8e1ddec2c78a..ae57b9ea0d41 100644
--- a/Documentation/nommu-mmap.txt
+++ b/Documentation/nommu-mmap.txt
@@ -43,12 +43,12 @@ and it's also much more restricted in the latter case:
even if this was created by another process.
- If possible, the file mapping will be directly on the backing device
- if the backing device has the BDI_CAP_MAP_DIRECT capability and
+ if the backing device has the NOMMU_MAP_DIRECT capability and
appropriate mapping protection capabilities. Ramfs, romfs, cramfs
and mtd might all permit this.
- If the backing device device can't or won't permit direct sharing,
- but does have the BDI_CAP_MAP_COPY capability, then a copy of the
+ but does have the NOMMU_MAP_COPY capability, then a copy of the
appropriate bit of the file will be read into a contiguous bit of
memory and any extraneous space beyond the EOF will be cleared
@@ -220,7 +220,7 @@ directly (can't be copied).
The file->f_op->mmap() operation will be called to actually inaugurate the
mapping. It can be rejected at that point. Returning the ENOSYS error will
-cause the mapping to be copied instead if BDI_CAP_MAP_COPY is specified.
+cause the mapping to be copied instead if NOMMU_MAP_COPY is specified.
The vm_ops->close() routine will be invoked when the last mapping on a chardev
is removed. An existing mapping will be shared, partially or not, if possible
@@ -232,7 +232,7 @@ want to handle it, despite the fact it's got an operation. For instance, it
might try directing the call to a secondary driver which turns out not to
implement it. Such is the case for the framebuffer driver which attempts to
direct the call to the device-specific driver. Under such circumstances, the
-mapping request will be rejected if BDI_CAP_MAP_COPY is not specified, and a
+mapping request will be rejected if NOMMU_MAP_COPY is not specified, and a
copy mapped otherwise.
IMPORTANT NOTE: