Per-open file private data for the cdevs

John Baldwin jhb at freebsd.org
Mon May 5 13:56:18 UTC 2008


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


More information about the freebsd-arch mailing list