Re: per file descriptor device callbacks ?

On Tue, Aug 28, 2012 at 01:38:13PM -0400, John Baldwin wrote:
> On Tuesday, August 28, 2012 1:26:06 pm Konstantin Belousov wrote:
> > On Tue, Aug 28, 2012 at 12:40:29PM -0400, John Baldwin wrote:
> > > On Tuesday, August 28, 2012 11:50:25 am Luigi Rizzo wrote:
> > > > On Mon, Aug 27, 2012 at 12:27:54PM -0400, John Baldwin wrote:
> > > > > On Monday, August 27, 2012 3:55:47 am Andriy Gapon wrote:
> > > > > > on 27/08/2012 10:34 Luigi Rizzo said the following:
> > > > > > > This requires to track calls to open/ioctl/poll/mmap/close.
> > > > > > > The difficulty i have is with mmap() and close(), because FreeBSD
> > > > > > > seems to handle these calls per-cdev rather than per-file-descriptor
> > > > > > > (for instance, no 'struct file' argument is available in mmap(), and
> > > > > > > the d_close method is only called on the last close() on the device).
> > > > > > 
> > > > > > devfs_set_cdevpriv(9), etc
> > > > > 
> > > > > mmap() is still problematic, but if you have the freedom to create your
> > > > > own VM objects, then d_mmap_single() can let you handle that fairly
> > > > > easily.
> > > > 
> > > > Would dev_clone(9) be a better way to do what i need ?
> > > > 
> > > > This way the struct cdev would be unique per file descriptor,
> > > > could be used as a key on the page fault callbacks
> > > > (i still do not have callbacks on dev_pager_ctor/dtor though).
> > > 
> > > dev_clone() is rather gross and a lot harder to use than
> > > devfs_set_cdevpriv().  If you are fine with the inherent problems
> > > of the device pager (you can't ever make mappings go away), you can
> > > just assign each client a unique offset into your shared object's
> > > memory space.  However, if you are exporting shared memory buffers,
> > > then a better model might be to let your clients use
> > > shm_open(SHM_ANON) to create buffers, then pass them into your driver
> > > via an ioctl() and use shm_map() to map them into the kernel.
> > 
> > Well, there is a new OBJT_MGTDEVICE pager, which together with
> > d_mmap_single() allows to have even per-mapping data. i915kms uses it.
> > You do not need cdevpriv for the per-mapping data.
> > 
> > Also, MGTDEVICE does track the mappings of the pages, so you can clean
> > up on device destruction.
> > 
> > Normal callbacks of the device pager allows to execute ctr/dtr methods
> > at the time of mapping creation and tear down.
> 
> These pages create PV entries so you can invalidate mappings when you
> invalidate a backing object, yes?  That is part of the problem with the
> standard device pager (no way to invalidate existing mappings of an
> object).
Right. Ability to invalidate the mappings of the device pages was the main
motivation for the new pager.

I forgot to mention that pmap shall properly handle fictitious managed pages
for the pager to work. It was fixed in the x86 pmaps, but I did not even
touched others.