drivers customizing mmap(2)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

I'd like to add a member fo_mmap to struct fileops so that cloning
devices can support mmap and use other kinds of uvm objects than just
uvm_deviceops and uvm_vnodeops.

Currently the only ways to customize mmap(2) are

. with a device node, by setting d_mmap in the struct cdevsw, but the
customization is very limited -- you have to use uvm_deviceops, and
you can't have per-open state for the device (e.g., with a cloning
device -- file descriptors for a cloning device have type DTYPE_MISC
which mmap(2) rejects); or

. with a file system, by providing VOP_MMAP, but you're limited to
uvm_vnodeops, and a file system is a complex beast.

Our drm code currently uses a non-cloning device for the drm(4) device
with some horrible bookkeeping kludges to associate per-open (really,
per-pid) state with the device.  I'd like to get rid of these horrible
bookkeeping kludges by using a cloning device, and the newer
incarnation of drm looks like it will require more of mmap(2) than
uvm_deviceops and uvm_vnodeops can straightforwardly provide,
including custom fault handlers.

I haven't fleshed out a detailed proposal or a patch to implement this
yet, but it should be fairly straightforward, and may help to clean up
some of the complex nests of conditionals in uvm_mmap.c.  Thoughts?