svn commit: r283998 - in head/sys: dev/drm dev/drm2 fs/devfs kern sys vm

[John Baldwin]

On Thursday, July 30, 2015 09:11:54 PM Oliver Pinter wrote:
> Hi John!
> 
> On Thu, Jun 4, 2015 at 9:41 PM, John Baldwin <jhb at freebsd.org> wrote:
> > Author: jhb
> > Date: Thu Jun  4 19:41:15 2015
> > New Revision: 283998
> > URL: https://svnweb.freebsd.org/changeset/base/283998
> >
> > Log:
> >   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:        https://reviews.freebsd.org/D2658
> >   Reviewed by:  alc (glanced over), kib
> >   MFC after:    1 month
> >   Sponsored by: Chelsio
> >
> > Modified:
> >   head/sys/dev/drm/drm_bufs.c
> >   head/sys/dev/drm2/drm_bufs.c
> >   head/sys/fs/devfs/devfs_vnops.c
> >   head/sys/kern/subr_uio.c
> >   head/sys/kern/uipc_shm.c
> >   head/sys/kern/vfs_vnops.c
> >   head/sys/sys/file.h
> >   head/sys/sys/mman.h
> >   head/sys/vm/vm_extern.h
> >   head/sys/vm/vm_mmap.c
> >
> 
> > ... patch trimmed...
> 
> When plan you to MFC this change to 10-STABLE?

There's a regression reported by sbruno@ that needs to be resolved before it
can be merged.  I might also need to employ an extra hack to preserve the ABI
(e.g. adding a new flag that has to be set in the fileops to say that the
fo_mmap field is present like was done for fo_truncate).

-- 
John Baldwin