[alsa-devel] [PATCH 0/4] ALSA: firewire: block .remove callback of bus

[Takashi Iwai]

On Wed, 10 Oct 2018 10:14:12 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Oct 10 2018 16:04, Takashi Iwai wrote:
> > On Wed, 10 Oct 2018 08:34:58 +0200,
> > Takashi Sakamoto wrote:
> >> In a discussion for devres support[1], I realize difference of unbind
> >> behaviour of drivers in ALSA firewire stack and in the others. For
> >> consistency behaviour inner the same subsystem for users, it's better
> >> to imitate the behaviour.
> >>
> >> Additionally, blocking .remove function simplifies codes to releasing
> >> device.
> >>
> >> This commit uses 'snd_card_free()' instead of
> >> 'snd_card_free_when_closed()' in .remove function and performs
> >> refactoring for release codes.
> >
> > Would the hot-unplug behavior change with this patch?
> >
> > For most of other drivers (but for USB), the actual hot-plug/unplug
> > are unlikely scenario, hence blocking makes sense to assure the safety
> > unbind.  (Yes, there is also PCI hotplug, but an audio device is
> > rarely used there.)
> >
> > But, FireWire is a beast to be plugged / unplugged more often, so the
> > hot-unplug behavior change is more important to users.
> 
> In a point of user experience, a slight change there is. From ether bus
> driver or sysfs nodes, unbind operation is successful. But it's blocked
> till all ALSA character devices are released. The user use 'unbind'
> sysfs node, command execution waits. In typical use cases of
> desktop environment, it waits that pulseaudio releases the last ALSA
> control character device.
> 
> In bus driver for IEEE 1394 bus, a call of .remove in device driver is
> done in workqueue. This bus operations runs without blocking.

OK, then that's fine.  The blocking in unbind can be considered rather
safer than the device hog-unplug, and the behavior change is justified
by that.

> If unbind operation is blocked in command line, it means that any
> program runs without no care of state of ALSA character devices. For
> example, current implementation of alsactl has this bug in its monitor
> mode[1]. The blocking state reminds users of this kind of bug of any
> applications.
> 
> Anyway, hot-plugging/unplugging are still available.
> 
> Rather than the slight change, this patchset performs refactoring codes
> for releasing devices. This removes complications of current code and
> simplify error paths.

Yes, that's a good bonus.  I'll read through your patches.


thanks,

Takashi