From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 04:07:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9191106566C; Wed, 29 Aug 2012 04:07:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBF18FC0A; Wed, 29 Aug 2012 04:07:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7T47n9i083753; Wed, 29 Aug 2012 07:07:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q7T47bHA070259; Wed, 29 Aug 2012 07:07:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7T47bTm070258; Wed, 29 Aug 2012 07:07:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Aug 2012 07:07:37 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120829040737.GS33100@deviant.kiev.zoral.com.ua> References: <20120827073403.GA49223@onelab2.iet.unipi.it> <201208281240.29612.jhb@freebsd.org> <20120828172606.GR33100@deviant.kiev.zoral.com.ua> <201208281338.13612.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GM/p8XWaonmYtdwv" Content-Disposition: inline In-Reply-To: <201208281338.13612.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Luigi Rizzo , current@freebsd.org, Andriy Gapon Subject: Re: per file descriptor device callbacks ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:07:44 -0000 --GM/p8XWaonmYtdwv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 Fre= eBSD > > > > > > > seems to handle these calls per-cdev rather than per-file-des= criptor > > > > > > > (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). > > > > > >=20 > > > > > > devfs_set_cdevpriv(9), etc > > > > >=20 > > > > > mmap() is still problematic, but if you have the freedom to creat= e your > > > > > own VM objects, then d_mmap_single() can let you handle that fair= ly > > > > > easily. > > > >=20 > > > > Would dev_clone(9) be a better way to do what i need ? > > > >=20 > > > > 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). > > >=20 > > > 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. > >=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 clean > > up on device destruction. > >=20 > > Normal callbacks of the device pager allows to execute ctr/dtr methods > > at the time of mapping creation and tear down. >=20 > 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. --GM/p8XWaonmYtdwv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA9lYgACgkQC3+MBN1Mb4inbgCgqRZ45YW9D70Ge0zNc9iv0qnE /dkAn0ILiXuNPMsfgspVVNt9Q9syLHOP =B186 -----END PGP SIGNATURE----- --GM/p8XWaonmYtdwv--