On Thu, 01 Mar 2018, Marc Herbert <Marc.Herbert@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
