public inbox for
help / color / mirror / Atom feed
From: Sebastian Huber <>
Subject: [newlib-cygwin] Add a new file operations hook for mmap
Date: Fri, 24 Aug 2018 13:09:00 -0000	[thread overview]
Message-ID: <> (raw);h=7cfc736e8911c2ad1fbd9d212264c44bcda45fbd

commit 7cfc736e8911c2ad1fbd9d212264c44bcda45fbd
Author: jhb <>
Date:   Thu Jun 4 19:41:15 2015 +0000

    Add a new file operations hook for mmap
    operations. File type-specific logic is now placed in the mmap hook
    implementation rather than requiring it to be placed in
    sys/vm/vm_mmap.c. This hook allows new file types to support mmap() as
    well as potentially allowing mmap() for existing file types that do not
    currently support any mapping.
    The vm_mmap() function is now split up into two functions.  A new
    vm_mmap_object() function handles the "back half" of vm_mmap() and accepts
    a referenced VM object to map rather than a (handle, handle_type) tuple.
    vm_mmap() is now reduced to converting a (handle, handle_type) tuple to a
    a VM object and then calling vm_mmap_object() to handle the actual mapping.
    The vm_mmap() function remains for use by other parts of the kernel
    (e.g. device drivers and exec) but now only supports mapping vnodes,
    character devices, and anonymous memory.
    The mmap() system call invokes vm_mmap_object() directly with a NULL object
    for anonymous mappings.  For mappings using a file descriptor, the
    descriptors fo_mmap() hook is invoked instead.  The fo_mmap() hook is
    responsible for performing type-specific checks and adjustments to
    arguments as well as possibly modifying mapping parameters such as flags
    or the object offset.  The fo_mmap() hook routines then call
    vm_mmap_object() to handle the actual mapping.
    The fo_mmap() hook is optional.  If it is not set, then fo_mmap() will
    fail with ENODEV.  A fo_mmap() hook is implemented for regular files,
    character devices, and shared memory objects (created via shm_open()).
    While here, consistently use the VM_PROT_* constants for the vm_prot_t
    type for the 'prot' variable passed to vm_mmap() and vm_mmap_object()
    as well as the vm_mmap_vnode() and vm_mmap_cdev() helper routines.
    Previously some places were using the mmap()-specific PROT_* constants
    instead.  While this happens to work because PROT_xx == VM_PROT_xx,
    using VM_PROT_* is more correct.
    Differential Revision:
    Reviewed by:	alc (glanced over), kib
    MFC after:	1 month
    Sponsored by:	Chelsio

 newlib/libc/sys/rtems/include/sys/mman.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/newlib/libc/sys/rtems/include/sys/mman.h b/newlib/libc/sys/rtems/include/sys/mman.h
index 53b656c..19d992e 100644
--- a/newlib/libc/sys/rtems/include/sys/mman.h
+++ b/newlib/libc/sys/rtems/include/sys/mman.h
@@ -230,8 +230,6 @@ struct shmfd {
 #ifdef _KERNEL
-int	shm_mmap(struct shmfd *shmfd, vm_size_t objsize, vm_ooffset_t foff,
-	    vm_object_t *obj);
 int	shm_map(struct file *fp, size_t size, off_t offset, void **memp);
 int	shm_unmap(struct file *fp, void *mem, size_t size);

                 reply	other threads:[~2018-08-24 13:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).