On 7/16/19 3:56 PM, Rob Herring wrote: > On Mon, Jul 15, 2019 at 7:05 PM Frank Rowand <frowand.list@xxxxxxxxx> wrote: >> >> On 7/15/19 11:40 AM, Saravana Kannan wrote: >>> Replying again because the previous email accidentally included HTML. >>> >>> Thanks for taking the time to reconsider the wording Frank. Your >>> intention was clear to me in the first email too. >>> >>> A kernel command line option can also completely disable this >>> functionality easily and cleanly. Can we pick that as an option? I've >>> an implementation of that in the v5 series I sent out last week. >> >> Yes, Rob suggested a command line option for debugging, and I am fine with >> that. But even with that, I would like a lot of testing so that we have a >> chance of finding systems that have trouble with the changes and could >> potentially be fixed before impacting a large number of users. > > Leaving it in -next for more than a cycle will not help. There's some I have to agree with your scepticism of the value of -next for this specific case. But I think there is a _tiny_ potential of additional testing if the feature is in more than one -next cycle. > number of users who test linux-next. Then there's more that test -rc > kernels. Then there's more that test final releases and/or stable > kernels. Probably, the more stable the h/w, the more it tends to be > latter groups. (I don't get reports of breaking PowerMacs with the > changes sitting in linux-next.) > > My main worry about this being off by default is it won't get tested. > I'm not sure there's enough interest to drive folks to turn it on and > test. Maybe it needs to be on until we see breakage. Agreed, but worried about the potential disruption when breakage occurs. -Frank > > Rob > . >
