Date: Mon, 5 May 2008 17:56:31 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs Message-ID: <20080505145631.GT18958@deviant.kiev.zoral.com.ua> In-Reply-To: <20080505081355.GB1628@garage.freebsd.pl> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505081355.GB1628@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080505145631.GT18958>