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?