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

[Takashi Iwai]

On Wed, 10 Oct 2018 10:25:30 +0200,
Takashi Iwai wrote:
> 
> 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.

... and applied all four patches now.  Thanks!


Takashi