Is there some implicit locking of device methods?

[John Baldwin]

On Wednesday, April 27, 2011 9:22:43 am 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?

Yes, if you only care about cleaning up per-fd data.

If you have some sort of state that needs to get created on first open and 
then removed on last close, you may still want to use a d_close() method, but 
there are actually edge cases where that can still not be called.  So, for 
that sort of data I would still depend on the cdevpriv destructor and use a 
reference count between open() and the destructor to know when to cleanup 
shared state.

-- 
John Baldwin