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

[Takashi Sakamoto]

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.

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.

[1] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2018-September/140580.html

Thanks

Takashi Sakamoto