Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Aug 2012 13:23:29 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        Andriy Gapon <avg@freebsd.org>, freebsd-current@freebsd.org, current@freebsd.org
Subject:   Re: per file descriptor device callbacks ?
Message-ID:  <20120829102329.GZ33100@deviant.kiev.zoral.com.ua>
In-Reply-To: <20120829045526.GA75216@onelab2.iet.unipi.it>
References:  <20120827073403.GA49223@onelab2.iet.unipi.it> <201208271227.54785.jhb@freebsd.org> <20120828155025.GA66068@onelab2.iet.unipi.it> <201208281240.29612.jhb@freebsd.org> <20120828172606.GR33100@deviant.kiev.zoral.com.ua> <20120828184226.GB68683@onelab2.iet.unipi.it> <20120829041240.GT33100@deviant.kiev.zoral.com.ua> <20120829045526.GA75216@onelab2.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help

--g2oeex4xcrwBLAZl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 29, 2012 at 06:55:26AM +0200, Luigi Rizzo wrote:
> On Wed, Aug 29, 2012 at 07:12:40AM +0300, Konstantin Belousov wrote:
> > On Tue, Aug 28, 2012 at 08:42:26PM +0200, Luigi Rizzo wrote:
> > > On Tue, Aug 28, 2012 at 08:26:06PM +0300, Konstantin Belousov wrote:
> > > ...
> > > > > 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 c=
an
> > > > > just assign each client a unique offset into your shared object's
> > > > > memory space.  However, if you are exporting shared memory buffer=
s,
> > > > > then a better model might be to let your clients use
> > > > > shm_open(SHM_ANON) to create buffers, then pass them into your dr=
iver
> > > > > via an ioctl() and use shm_map() to map them into the kernel.
> > > >=20
> > > > 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.
> > > >=20
> > > > Also, MGTDEVICE does track the mappings of the pages, so you can cl=
ean
> > > > up on device destruction.
> > >=20
> > > interesting, thanks for the pointer, i'll look it up in i915kms.
> > > Does this exist also in stable/9 ?
> > > It would be a shame otherwise...
> > Yes, it was merged.
> >=20
> > >=20
> > > > Normal callbacks of the device pager allows to execute ctr/dtr meth=
ods
> > > > at the time of mapping creation and tear down.
> > >=20
> > > what would be a good way to install my own ctr/dtr methods ?
> > > I only found out a rather crude one, and it only works for
> > > the destructor:
> > See below.
> >=20
> > >=20
> > >     static struct cdev_pager_ops saved_cdev_pager_ops;
> > >     static struct cdev_pager_ops netmap_cdev_pager_ops;
> > >=20
> > >     static void
> > >     netmap_dev_pager_dtor(void *handle)
> > >     {
> > >         saved_cdev_pager_ops.cdev_pg_dtor(handle);
> > > 	// my code here
> > >         D("ready to release memory for %p", handle);
> > >     }
> > >=20
> > >=20
> > >     static int
> > >     netmap_mmap_single(struct cdev *cdev, vm_ooffset_t *foff,
> > > 		vm_size_t objsize,  vm_object_t *objp, int prot)
> > >     {
> > >         vm_object_t obj;
> > > =20
> > > 	/* XXX check size etc. */
> > >         obj =3D vm_pager_allocate(OBJT_DEVICE, cdev, objsize, prot, *=
foff,
> > >             curthread->td_ucred);
> > Use cdev_pager_allocate().
> >=20
> > >         if (obj =3D=3D NULL)
> > >                 return EINVAL;
> > >         if (saved_cdev_pager_ops.cdev_pg_fault =3D=3D NULL) {
> > I do not understand what are you trying to accomplish with the
> > check and reinitialization, but I assume that cdev_pager_allocate()
> > would take care of it.
>=20
> First and foremost, I am trying to do things without
> requiring kernel modifications.
This is strange.

>=20
> I am trying to reuse the constructor and destructor of the standard
> device pager, and around those add my own calls.  Those methods are
> declared static in sys/vm/device_pager.c so i cannot invoke directly
> cdev_pager_allocate().
I fail to see how can you use old_dev_pager_{ctor,dtor} without
also using the d_mmap.

Note that use of d_mmap _does not_ mean that access to the mapped
area never faults.

I suggest you to go fully 'mgmt device pager' route.

>=20
> I could indeed rewrite the body of those three methods
> (ctor, dtor, fault) in my own code.  I will look at this today.
> Perhaps I could even try to install all mappings at mmap() time so
> I never need to fault.
>=20
> Thanks again for the suggestions
>=20
> cheers
> luigi
>=20
>=20
> > >                 D("initialize cdev_pager_ops");
> > >                 saved_cdev_pager_ops =3D *(obj->un_pager.devp.ops);
> > >                 netmap_cdev_pager_ops =3D *(obj->un_pager.devp.ops);
> > >                 netmap_cdev_pager_ops.cdev_pg_dtor =3D netmap_dev_pag=
er_dtor;
> > >         };
> > >         obj->un_pager.devp.ops =3D &netmap_cdev_pager_ops;
> > >         *objp =3D obj;
> > > 	/* XXX perhaps do something more here, such as install
> > > 	 * mappings for the pages so we have no faults later.
> > > 	 */
> > >         return 0;
> > >     }
> > >=20
> > >     static struct cdevsw netmap_cdevsw =3D {
> > >         .d_version =3D D_VERSION,
> > >         .d_name =3D "netmap",
> > >         .d_open =3D netmap_open,
> > >         .d_mmap =3D netmap_mmap,
> > >         .d_mmap_single =3D netmap_mmap_single,
> > >         .d_ioctl =3D netmap_ioctl,
> > >         .d_poll =3D netmap_poll,
> > >         .d_close =3D netmap_close,
> > >     };
> > >=20
> > > cheers
> > > luigi
>=20

--g2oeex4xcrwBLAZl
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAlA97aEACgkQC3+MBN1Mb4hQcwCfcChxtRndLaHjsGA559tJlu8X
2UEAn2GPyuv1FIRYLuNFYOmZXHPZ+7tI
=aNyB
-----END PGP SIGNATURE-----

--g2oeex4xcrwBLAZl--



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