From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:56:41 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1F381065672; Mon, 5 May 2008 14:56:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 70B818FC15; Mon, 5 May 2008 14:56:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jt27M-000KhX-2W; Mon, 05 May 2008 17:56:40 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45EuacF065488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 17:56:36 +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.2/8.14.2) with ESMTP id m45EuWYa010614; Mon, 5 May 2008 17:56:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m45EuVk7010613; Mon, 5 May 2008 17:56:31 +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: Mon, 5 May 2008 17:56:31 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20080505145631.GT18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505081355.GB1628@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zCRYTTfePT7f+iLT" Content-Disposition: inline In-Reply-To: <20080505081355.GB1628@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 44556c58cf61beb49de4494ee559d59c X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2780 [May 05 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 14:56:42 -0000 --zCRYTTfePT7f+iLT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 05, 2008 at 10:13:55AM +0200, Pawel Jakub Dawidek wrote: > On Sun, May 04, 2008 at 08:10:02PM +0300, Kostik Belousov wrote: > > Since the review for the clone-at-open patch (fdclone) posted some time= ago > > mostly says that it would be better to implement per-file private data > > instead, I produced the patch along this line, > >=20 > > The patch does not change the cdevsw ABI, instead, three new functions > > nt devfs_get_cdevpriv(void **datap); > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > void devfs_clear_cdevpriv(void); > > are provided for manipulation of the per-file private data. > >=20 > > devfs_set_cdevpriv assigns the priv as private data for the file descri= ptor > > which is used to initiate currently performed driver operation. dtr > > is the function that will be called when either the last refernce to > > the file goes away or devfs_clear_cdevpriv is called. > >=20 > > devfs_get_cdevpriv is the obvious accessor. > >=20 > > devfs_clear_cdevpriv allows to clear the private data for the still > > open file. > >=20 > > The synchronization of the cdev data and file private data is left > > to the driver code, I did not found any generic helper mechanism that > > could be useful there. > >=20 > > Patch: > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > >=20 > > Dumb driver that shows the basic usage of the proposed KPI: > > http://people.freebsd.org/~kib/misc/fpclone.c > >=20 > > Previous version of the patch was tested by Peter Holm. >=20 > Can you see if my OSD (Object-Specific-Data) KPI can be useful here? > I've it only in perforce for now, but I think it's what you are looking > for. I use it for jails and threads currently, but it is trivial to use > it for other objects. Take a look: >=20 > http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/user/pjd/zfs/s= ys/sys/osd.h&REV=3D3 >=20 > When your code is loaded/initialized you call: >=20 > static int slot; >=20 > slot =3D osd_file_register(mod_destroy); >=20 > Where mod_destroy is a function which knows how to free your private > data. On unload: >=20 > osd_file_deregister(slot); >=20 > Now, when you want to attach private data: >=20 > error =3D osd_file_set(fp, slot, ptr_to_your_data); >=20 > You can get it with: >=20 > ptr =3D osd_file_get(fp, slot); This is a nice feature, but I think that privdata is a fundamental internal operation of the kernel, and it would be wrong to use the OSD. In fact, the object we shall attach OSD to is the struct file, and we would need to export the struct file to the cdevsw operations. Since it both breaks current ABI and complicates the future changes to the struct file, I would much prefer to not engage this route. --zCRYTTfePT7f+iLT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgfIB8ACgkQC3+MBN1Mb4ihBACeJwZ/qjNycP+iQNIfM8otx5y7 cuYAoMNYcHQkOChjycGdnaX88udAxm8v =DBHl -----END PGP SIGNATURE----- --zCRYTTfePT7f+iLT--