Date: Wed, 27 Apr 2011 13:34:07 -0400 From: John Baldwin <jhb@freebsd.org> To: Bartosz Fabianowski <freebsd@chillt.de> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: Is there some implicit locking of device methods? Message-ID: <201104271334.07170.jhb@freebsd.org> In-Reply-To: <4DB818A3.1020104@chillt.de> References: <4DB695DB.1080505@chillt.de> <201104271019.31844.jhb@freebsd.org> <4DB818A3.1020104@chillt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104271334.07170.jhb>