linux-imx

=============================

No-MMU memory mapping support

=============================

​

The kernel has limited support for memory mapping under no-MMU conditions, such

as are used in uClinux environments. From the userspace point of view, memory

mapping is made use of in conjunction with the mmap() system call, the shmat()

call and the execve() system call. From the kernel's point of view, execve()

mapping is actually performed by the binfmt drivers, which call back into the

mmap() routines to do the actual work.

​

Memory mapping behaviour also involves the way fork(), vfork(), clone() and

ptrace() work. Under uClinux there is no fork(), and clone() must be supplied

the CLONE_VM flag.

​

The behaviour is similar between the MMU and no-MMU cases, but not identical;

and it's also much more restricted in the latter case:

​

 (#) Anonymous mapping, MAP_PRIVATE

​

    In the MMU case: VM regions backed by arbitrary pages; copy-on-write

    across fork.

​

    In the no-MMU case: VM regions backed by arbitrary contiguous runs of

    pages.

​

 (#) Anonymous mapping, MAP_SHARED

​

    These behave very much like private mappings, except that they're

    shared across fork() or clone() without CLONE_VM in the MMU case. Since

    the no-MMU case doesn't support these, behaviour is identical to

    MAP_PRIVATE there.

​

 (#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, !PROT_WRITE

​

    In the MMU case: VM regions backed by pages read from file; changes to

    the underlying file are reflected in the mapping; copied across fork.

​

    In the no-MMU case:

​

         - If one exists, the kernel will re-use an existing mapping to the

           same segment of the same file if that has compatible permissions,

           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 NOMMU_MAP_DIRECT capability and

           appropriate mapping protection capabilities. Ramfs, romfs, cramfs

           and mtd might all permit this.

​

     - If the backing device can't or won't permit direct sharing,

           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

​

     - Writes to the file do not affect the mapping; writes to the mapping

       are visible in other processes (no MMU protection), but should not

       happen.

​

 (#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, PROT_WRITE

​

    In the MMU case: like the non-PROT_WRITE case, except that the pages in

    question get copied before the write actually happens. From that point

    on writes to the file underneath that page no longer get reflected into

    the mapping's backing pages. The page is then backed by swap instead.

​

    In the no-MMU case: works much like the non-PROT_WRITE case, except

    that a copy is always taken and never shared.

​

 (#) Regular file / blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE

​

    In the MMU case: VM regions backed by pages read from file; changes to

    pages written back to file; writes to file reflected into pages backing

    mapping; shared across fork.

​

    In the no-MMU case: not supported.

​

 (#) Memory backed regular file, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE

​

    In the MMU case: As for ordinary regular files.

​

    In the no-MMU case: The filesystem providing the memory-backed file

    (such as ramfs or tmpfs) may choose to honour an open, truncate, mmap

    sequence by providing a contiguous sequence of pages to map. In that

    case, a shared-writable memory mapping will be possible. It will work

    as for the MMU case. If the filesystem does not provide any such

    support, then the mapping request will be denied.

​

 (#) Memory backed blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE

​

    In the MMU case: As for ordinary regular files.

​

    In the no-MMU case: As for memory backed regular files, but the