On Tue, Mar 05, 2013 at 12:31:37AM +0000, Taylor R Campbell wrote: > 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?
At $DAYJOB we wanted an mmap-able character device both to manage the VA->PA mapping protection (read-only, read-write), to handle faults, and to remove mappings under certain conditions. It looked to me like the uvm_pagerops structure encapsulated all of the functions that our device needed to supply, but I could find no way for a character device to supply a custom uvm_pagerops for an mmap'd region. I thought that perhaps the device's cdevsw could provide an alternate to d_mmap, int (*d_get_pagerops)(dev_t, struct uvm_pagerops **) or something, for uvm_mmap to call. Dave -- David Young dyo...@pobox.com Urbana, IL (217) 721-9981