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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
