[Intel-gfx] *cringe* at adding a parameter to workaround issues.

[Jani Nikula]

On Thu, 01 Mar 2018, Marc Herbert <Marc.Herbert at intel.com> wrote:
> Hi Jani,
>
>> *cringe* at adding a parameter to workaround issues.
>
> I understand that *each* parameter has the potential to *multiply* the total
> number of configurations and that the resulting combinatorial explosion is
> absolutely not scalable and sustainable from a validation perspective. No
> one should expect to get support here when options like this one are set to
> a non-default value.
>
> When something breaks on the other hand, transparent _test_ knobs like this
> one have proved invaluable countless times to help troubleshoot and isolate
> issues. It's at least 10 times more productive to ask a non-expert in some
> opposite timezone "please test again after rebooting with this parameter"
> compared to "test again after applying this patch, recompiling, etc." -
> assuming the latter has any chance of success at all.  I'm speaking from
> actual experience as we are routinely experiencing both type of situations.

Yes, I do understand, and that's why it's a "cringe", not a "nak".

The flip side are bug reports that we still get regardless of warnings
in dmesg and kernel taint when people try out parameters that they read
about in random forums, and expect support. And lack of bug reports when
people silently workaround their issues using module parameters.

> I hope the "unsafe" part of "i915_param_named_unsafe" provides a permanent
> solution to both problems by making a clear distinction between the only one
> single true supported configuration on one hand versus test datapoints
> on the other hand.  Same for "tainted", sysfs or else.

This is what I hoped too when I added support for the "unsafe"
parameters. :) Now I wish we could move this stuff to debugfs and flip
debugfs options as easily as module parameters. I think this is the
primary reason we have so many debugging module parameters: they are
more convenient than debugfs.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center