Hi Mark,
On Wed, Mar 11, 2020 at 12:25:31PM +0000, Mark Brown wrote:
On Wed, Mar 11, 2020 at 08:41:27AM +0100, Guennadi Liakhovetski wrote:
On Tue, Mar 10, 2020 at 12:45:44PM +0000, Mark Brown wrote:
So why doesn't DPCM recognize that the path is inactive and why is it better to do this than fix whatever the issue is there?
Of course that would be better abd I'd much prefer that. Unfortunately I haven't been able to find a single scenario in which those paths would be exercised. As far as I understand path pruning should take place e.g. when a mixer modifies audio routing and as a result disables a certain pipeline, which is then pruned. If I could reproduce such a scenario I would be able to first check whether it's working, then see exactly how it is working and then see how best to add my use case to it. Since I wasn't able to find such a scenario, my only option was to preserve the current state and add my own path "on top." I'd be happy to try the other path too, I just need a use case, that I can reproduce.
It's still not clear to me what the issue is here. If something is making a modification to the graph which needs a recheck or update I'd expect that these things happen along with that modification. I don't understand what you're saying about not being able to reproduce scenarios or adding things "on top".
I mean, that I don't have a test-case to test dpcm_prune_paths() without my VirtIO support. That function currently exists in the kernel, but I don't have a test-case to verify its work, to see it called and actually perform the pruning. So I don't know how it is supposed to work. And because of that I cannot fix my VirtIO use case to use that function properly, without forcing it with an additional parameter.
Thanks Guennadi