Is there some implicit locking of device methods?

[Kostik Belousov]

On Wed, Apr 27, 2011 at 03:22:43PM +0200, Bartosz Fabianowski wrote:
> >Err, if you use cdevpriv you shouldn't even have a d_close method.  All 
> >your
> >d_close logic should be in the cdevpriv destructor
> 
> I see. There is no documentation for any of this, so I just implemented 
> it in the way I *thought* it should work:
> 
> .d_close = drv_close,
> 
> int drv_close(...) {
>   devfs_clear_cdevpriv();
> }
> 
> static void cdevpriv_dtr(void *data) {
>   free(data, M_USBDEV);
> }
> 
> If I understand you correctly, I can leave out the drv_close() method. 
> When close() is called, devfs_clear_cdevpriv() will be executed 
> implcitly for me and my dstructor will run - right?

You are mixing the global 'last close', that is performed when last file
opened over the device node is closed, and the last filedescriptor close
which causes the file to be decomissioned.

The global kind of last close is communicated to cdev by calling cdevsw
close method. It is known to be not quite reliable, and esp. hard in
relation to the forced unmounts of devfs mount points.

The close of file (when no other file descriptors referencing the file are
left) ends in cdevpriv destructor call.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110427/00016c74/attachment.pgp