On 7.08.2023 21:05, Bryan O'Donoghue wrote: > On 07/08/2023 19:55, Konrad Dybcio wrote: >> On 7.08.2023 20:49, Bryan O'Donoghue wrote: >>> On 07/08/2023 19:45, Konrad Dybcio wrote: >>>> That can be taken care of with match data. >>>> >>>> Konrad >>> >>> Well perhaps. >>> >>> I'm just sticking my oar in, to elucidate. >>> >>> The compat sub-nodes aren't just a random choice with no logic. They exist to select between what you assign the blocks to be, encoder, decoder or any admixture thereof. >>> >>> A functionality we want to maintain. >> Surely something like a modparam would be more suitable here? >> >> Konrad > > Hmm. > > Well from earlier in the thread the question "why do we have these compat strings" is because we can have any combination of encoder/decoder assigned. > > If there's a cogent argument _still_ to be made to transition to some new way of assignment then fine so long as we don't break that basic flexibility. > > Though my own €0.02 is that a module parameter is more of a PITA than a compat string. > > OTOH I could make the argument, that the high probability is most people - probably all, just instantiate a single encoder and decoder and aren't aware of or using the inbuilt flexibility. > > @stan probably has the right idea what to do. Actually.. Has anybody tested this, ever, with the mainline driver? Do we have anyone using this? Is anybody willing to maintain that, test for regressions and fix them in a reasonable amount of time? If we don't have at least 2x "yes" here, I don't think it makes sense to worry about it.. Konrad
