Per-open file private data for the cdevs

[Kostik Belousov]

On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote:
> 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).)

Probably, I shall clarify that the dtr is called when the last reference
to the struct file going away, unless the priv data is already cleared
by the call to the devfs_clear_cdevpriv.

The problem with VOP_CLOSE() is that some actions (like forced unmount
or revoke) may cause less calls to the devfs_close then the files
pointing to the cdev. Your proposal basically means that we need,
besides the normal pointers file->vnode->cdev, have the reverse path
cdev->file. I think this is ugly and better be handled by the fdrop().

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080505/5dc3d009/attachment.pgp