Page MenuHomeFreeBSD

Don't do the busy dance in icee_open/close
ClosedPublic

Authored by imp on Sep 2 2020, 5:43 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sep 26 2024, 2:06 PM
Unknown Object (File)
Sep 17 2024, 9:40 PM
Unknown Object (File)
Sep 16 2024, 10:09 PM
Unknown Object (File)
Sep 16 2024, 4:26 PM
Unknown Object (File)
Sep 12 2024, 11:47 AM
Unknown Object (File)
Sep 7 2024, 11:42 PM
Unknown Object (File)
Sep 5 2024, 12:53 AM
Unknown Object (File)
Aug 13 2024, 6:09 AM
Subscribers

Details

Reviewers
ian
Summary

We don't need to do the busy dance for this driver. It's handled by
destroy_dev() entirely. Since all we did was busy/unbusy in
open/close, just delete them. We therefore don't need to track closes
either.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 33334
Build 30645: arc lint + arc unit

Event Timeline

imp requested review of this revision.Sep 2 2020, 5:43 PM
imp created this revision.

So, what prevents "kldunload icee" while someone has the cdev open?

In D26302#584633, @ian wrote:

So, what prevents "kldunload icee" while someone has the cdev open?

Nothing. Just like we don't do it for almost all other devices. If that's really needed, we should do it via the device_quesce mechanism.

In D26302#584718, @imp wrote:
In D26302#584633, @ian wrote:

So, what prevents "kldunload icee" while someone has the cdev open?

Nothing. Just like we don't do it for almost all other devices. If that's really needed, we should do it via the device_quesce mechanism.

Huh. I didn't know about device_quiesce(), it might not have existed when I added the busy/unbusy to icee. There's no manpage describing it, but the implementation is easy enough to figure out (and I think it may be wrong, DS_ATTACHING state should probably yield EBUSY).

I guess I was just over-thinking things when I added the busy/unbusy to prevent unloading; repo archaeology shows I added them in the commit "Make icee usable as a module". I think I also didn't understand the TRACKCLOSE flag back then, and it should never have been included.

This revision is now accepted and ready to land.Sep 3 2020, 2:54 PM