Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Aug 2012 12:40:29 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        freebsd-current@freebsd.org, current@freebsd.org, Andriy Gapon <avg@freebsd.org>
Subject:   Re: per file descriptor device callbacks ?
Message-ID:  <201208281240.29612.jhb@freebsd.org>
In-Reply-To: <20120828155025.GA66068@onelab2.iet.unipi.it>
References:  <20120827073403.GA49223@onelab2.iet.unipi.it> <201208271227.54785.jhb@freebsd.org> <20120828155025.GA66068@onelab2.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208281240.29612.jhb>