fd: Move from using device_busy to a refcount

[imp]

Summary

Use refcounting to delay the detach rather than device_busy and/or
device_unbusy. fd/fdc is one of the few consumers of device_busy in the
tree for that, and it's not a good fit. Also, nothing is waking 'fd' so
the loop in detach could never be broken, so switch to pause (maybe it
should switch to EBUSY).

Sponsored by: Netflix

Test Plan

I've not yet tested this, but will need to in a VM since I don't have any real floppy hardware.

[imp]

return EBUSY when things are open to match everything else

[mav]

I think detach method should be aggressive, not looking for busy, since in many cases its call means the device is no longer there or soon won't be. So you should just call fd_detach_geom as it was and then wait for providergone GEOM callback to be called. That callback is a relatively new thing, it was not there originally, that is why open counting was used.

[imp]

update to use provider gone, per mav@

[imp]

In D31830#718045, @mav wrote:

I think detach method should be aggressive, not looking for busy, since in many cases its call means the device is no longer there or soon won't be. So you should just call fd_detach_geom as it was and then wait for providergone GEOM callback to be called. That callback is a relatively new thing, it was not there originally, that is why open counting was used.

Ah! That's the mechanism that makes more sense than moving to refcount. Good call! Thanks. I've updated with what I think you are suggesting. Not 100% sure of the 'wait' placement, but I think it's better after we drain the motor off callout.

[imp]

Add comment to say we turn off motor in fdc_detach

[imp]

sys/dev/fdc/fdc.c

1592

This is likely gratuitous, but not worth doing as a separate change.

[mav]

I think we should drain after the wait, since some operations may still complete while we are waiting, or it may take time for consumers to release us, so why not operate the motor in process? Actually it seems not only motor off, but also motor on, and we may need it to handle already active requests.

[imp]

In D31830#718082, @mav wrote:

I think we should drain after the wait, since some operations may still complete while we are waiting, or it may take time for consumers to release us, so why not operate the motor in process? Actually it seems not only motor off, but also motor on, and we may need it to handle already active requests.

I think you're right we need to move it. I'll do that and update.

[imp]

Move drain to after we wait for the wither to finish since we may need to access
the drive (and that may turn on the motor (speculative)). Add comment explaining
this in a little detail....