Is there some implicit locking of device methods?

[Kostik Belousov]

On Wed, Apr 27, 2011 at 11:14:36PM +0200, Bartosz Fabianowski wrote:
> >If you have some sort of state that needs to get created on first
> >open and then removed on last close [...] 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.
> 
> Yes, this is what I am doing. I am maintaining a list of all file 
> descriptors open on the device. Once the length of that list reaches 
> zero, I do global clean-up in the cdevpriv destructor.

You are mixing things, and do repeat the work (probably buggy) that is
already done by devfs. You should understand the relationship between
basic concepts first.

File descriptor != opened file != cdev node. Driver indeed may get
notifications on all open(2) syscalls performed on the node, but is has
absolutely no way to enumerate filedescriptors referencing that files.
cdevpriv is per file, not per node. cdevpriv is cleaned automatically
when last filedescriptor referencing the file is gone, not when the last
file referencing the node is closed. The later is approximated by
d_close().
-------------- 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/8d33059d/attachment.pgp