Date: Mon, 5 May 2008 09:39:42 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Kostik Belousov <kostikbel@gmail.com> Subject: Re: Per-open file private data for the cdevs Message-ID: <200805050939.42425.jhb@freebsd.org> In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 04 May 2008 01:10:02 pm 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, > > 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. > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > 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. > > devfs_get_cdevpriv is the obvious accessor. > > devfs_clear_cdevpriv allows to clear the private data for the still > open file. > > 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. > > Patch: > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > Dumb driver that shows the basic usage of the proposed KPI: > http://people.freebsd.org/~kib/misc/fpclone.c > > Previous version of the patch was tested by Peter Holm. I like this very much and will use it instead of devfs cloning in ipmi(4) so we can use ipmievd when it is committed. IWBN if there was a more automated way of handling the unload race, for example if destroy_dev() could somehow clear all the per-open fd data. That may not be easily feasible, however. (In theory each cdev could have a list of "attached" 'struct file' objects that it updates in VOP_CLOSE() and for a destroy dev it detaches all the private data after marking the cdev with a bad/null cdevsw, however, that would bloat 'struct file' with at least one more pointer (if not two).) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805050939.42425.jhb>