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
