Lines Matching +full:memory +full:- +full:mapping
2 No-MMU memory mapping support
5 The kernel has limited support for memory mapping under no-MMU conditions, such
6 as are used in uClinux environments. From the userspace point of view, memory
7 mapping is made use of in conjunction with the mmap() system call, the shmat()
9 mapping is actually performed by the binfmt drivers, which call back into the
12 Memory mapping behaviour also involves the way fork(), vfork(), clone() and
16 The behaviour is similar between the MMU and no-MMU cases, but not identical;
19 (#) Anonymous mapping, MAP_PRIVATE
21 In the MMU case: VM regions backed by arbitrary pages; copy-on-write
24 In the no-MMU case: VM regions backed by arbitrary contiguous runs of
27 (#) Anonymous mapping, MAP_SHARED
31 the no-MMU case doesn't support these, behaviour is identical to
37 the underlying file are reflected in the mapping; copied across fork.
39 In the no-MMU case:
41 - If one exists, the kernel will re-use an existing mapping to the
45 - If possible, the file mapping will be directly on the backing device
47 appropriate mapping protection capabilities. Ramfs, romfs, cramfs
50 - If the backing device can't or won't permit direct sharing,
53 memory and any extraneous space beyond the EOF will be cleared
55 - Writes to the file do not affect the mapping; writes to the mapping
61 In the MMU case: like the non-PROT_WRITE case, except that the pages in
64 the mapping's backing pages. The page is then backed by swap instead.
66 In the no-MMU case: works much like the non-PROT_WRITE case, except
73 mapping; shared across fork.
75 In the no-MMU case: not supported.
77 (#) Memory backed regular file, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
81 In the no-MMU case: The filesystem providing the memory-backed file
84 case, a shared-writable memory mapping will be possible. It will work
86 support, then the mapping request will be denied.
88 (#) Memory backed blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
92 In the no-MMU case: As for memory backed regular files, but the
95 all its memory as a contiguous array upfront.
97 (#) Memory backed chardev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
101 In the no-MMU case: The character device driver may choose to honour
103 provides memory or quasi-memory that can be accessed directly. Examples
105 provide any such support, then the mapping request will be denied.
108 Further notes on no-MMU MMAP
111 (#) A request for a private mapping of a file may return a buffer that is not
112 page-aligned. This is because XIP may take place, and the data may not be
115 (#) A request for an anonymous mapping will always be page aligned. If
117 of the space may be wasted as the kernel must allocate a power-of-2
121 (#) The memory allocated by a request for an anonymous mapping will normally
130 initialize the contents of a page - depending on the write-usage of the
131 mapping.
133 In the no-MMU case, however, anonymous mappings are backed by physical
136 anonymous mapping and the kernel then does a memset for the entire map.
138 However, for memory that isn't required to be precleared - such as that
139 returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
140 indicate to the kernel that it shouldn't bother clearing the memory before
144 uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
148 visible through /proc/maps in no-MMU mode.
151 /proc/<pid>/maps in no-MMU mode.
153 (#) Supplying MAP_FIXED or a requesting a particular mapping address will
157 driver or filesystem so that the contents can be read into the memory
163 Interprocess shared memory
166 Both SYSV IPC SHM shared memory and POSIX shared memory is supported in NOMMU
176 mappings made by a process or if the mapping in which the address lies does not
177 support futexes (such as an I/O chardev mapping).
180 No-MMU mremap
184 mapping, and may move it [#]_ if MREMAP_MAYMOVE is specified and if the new size
185 of the mapping exceeds the size of the slab object currently occupied by the
186 memory to which the mapping refers, or if a smaller slab object could be used.
197 act on a complete mapping.
206 file->f_op->get_unmapped_area() operation. The mmap() routines will call this
207 to get a proposed address for the mapping. This may return an error if it
208 doesn't wish to honour the mapping because it's too long, at a weird offset,
212 to indicate the permitted types of mapping on such devices. The default is
216 The file->f_op->mmap() operation will be called to actually inaugurate the
217 mapping. It can be rejected at that point. Returning the ENOSYS error will
218 cause the mapping to be copied instead if NOMMU_MAP_COPY is specified.
220 The vm_ops->close() routine will be invoked when the last mapping on a chardev
221 is removed. An existing mapping will be shared, partially or not, if possible
224 It is permitted also for the file->f_op->get_unmapped_area() operation to
225 return -ENOSYS. This will be taken to mean that this operation just doesn't
229 direct the call to the device-specific driver. Under such circumstances, the
230 mapping request will be rejected if NOMMU_MAP_COPY is not specified, and a
238 status reflected in the mapping, instead of the data.
241 private mapping showing such information when the driver is busy
247 Providing shareable memory-backed file support
250 Provision of shared mappings on memory backed files is similar to the provision
257 enough pages to honour a mapping. This is required to support POSIX shared
258 memory.
260 Memory backed devices are indicated by the mapping's backing device info having
269 should allocate sufficient contiguous memory to honour any supported mapping.
275 NOMMU mmap automatically rounds up to the nearest power-of-2 number of pages
276 when performing an allocation. This can have adverse effects on memory
279 allocator. In order to retain finer-grained control over fragmentation, this