At Wed, 14 Jan 2015 12:02:28 +0000, Mark Brown wrote:
On Wed, Jan 14, 2015 at 11:50:48AM +0100, Takashi Iwai wrote:
Lars-Peter Clausen wrote:
OK, so it's not about active stream. From the reporter's description, I supposed that the module gets unloaded while playing a stream, which shouldn't be allowed.
Well one of the ways to trigger this is to remove the module while the stream is active. But it is not exclusively a problem module unload problem. E.g. the same happens if you hot-unplug the ASoC card.
Yes, unbinding can trigger a similar problem, ends up the same bad code path.
Right, which was my point - we need to be able to cope with the driver being removed while in use, unbind is just one path where this could happen and the issue isn't specific to unbind.
I don't think that we need to prevent module unload when a stream is active. From a framework point of view is not different from hot-unplug. I don't see a reason why we'd jump through hoops to actively forbid removing the module once it works just fine.
Well, the module unload means a more drastic cleanup. Even if you unbind, the code and data are still there while module unload may clean them up all.
Above all, disallowing the module unload while using is the common behavior of any other drivers. Why do we have to be a rebel against all civil manner? :)
That's not true for everything
Hmm, which driver does behave so intentionally? I'm interested in the supposed reason behind it.
and for ASoC I'd tend to assume that the user knows what they're doing and has a good reason for it; it's certainly something that can be helpful in development.
The module unload is never considered to be equivalent with hot unplug It's more than that.
Takashi