[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
drivers customizing mmap(2)
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?
Main Index |
Thread Index |