* David Brownell <david-b@xxxxxxxxxxx> wrote: > > nowhere did i suggest that it should be default-enabled ... > > The patch you asked to be merged *DID* have it be default-enabled! So > you did more than just "suggest"... if that option is enabled in > Kconfig, this test is always forced on and it will cause failures on > systems where STR has never worked. i think you dont understand what "default enabled" means in this context. Default enabled means the Kconfig entry has a "default y" line - which it did not have in the patch i sent. if a tester enables the .config option then it is very much expected to be triggered, just like the other .config debug options. Of course, the tester specifically enabled it, so that's what we want to happen. Not some other "yes_i_really_meant_it" boot option ... There can also be _another_ .config option that turns off the 'run by default' property - but if someone selects the _default off_ feature and enables it, just like i did, then the feature is very much expected to run. you really seem to have deep misunderstandings about how testers use Linux, what it takes to build up a proper debug infrastructure and how to utilize all these things to make Linux better. You come from the embedded world where everything is configured together specifically, where people know what they are using and were every feature is well accounted for. But you seem to have little insight into how distributions utilize kernel features and what it takes to accept the help of testers who dont know the field that well but still want to help out - as long as we let them. These are well-established practices we use in all other debug features that help Linux today, and what you are asking for is weird, unusual and wrong. Please take a look at how all the other debug stuff works. Rule #1: testers dont have to beg the kernel for 1 hour and have to write 2 patches to let the test code be run finally ... ;-) This isnt even about any nuances where reasonable people might disagree, this is really basic testing-101 stuff. Ingo _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
