On Wed, Nov 30, 2016 at 6:19 PM, Justin Forbes <jforbes@xxxxxxxxxx> wrote: > On Wed, Nov 30, 2016 at 4:33 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> > wrote: >> >> On Wed, Nov 30, 2016 at 5:29 PM, Paul Bolle <pebolle@xxxxxxxxxx> wrote: >> > On Wed, 2016-11-30 at 17:15 -0500, Don Zickus wrote: >> >> I noticed that CONFIG_MODVERSIONS was not enabled in Fedora. I do not >> >> know >> >> the history and would be curious to know if someone knew. > > > As for reasoning that it is turned off, I expect that is because it > originally came into the kernel (2.6 days I think) as EXPERIMENTAL. By > policy, we don't enable anything requiring CONFIG_EXPERIMENTAL without > justification. Though since EXPERIMENTAL is turned on for the occasional > thing that is justified, it means we have to turn off those things manually > in the config. Rarely are those options revisited unless someone asks. > That said, it is no longer EXPERIMENTAL. > > >> >> >> Otherwise, I would like to propose enabling it. > > > While I don't think it really does much to help with the 3rd party driver > situation in Fedora, I am all for helping RHEL. In the Fedora case we are > rebasing pretty frequently. and following the stable branch in between. As a > result, most people are using either dkms or akmod to manage their 3rd party > drivers. Most of the bugs we do get are 3rd party drivers which just don't > work with the latest kernel due to actual code changes or conflicts (such as > upstream adding a new function that just happens to share a name with an > nvidia function). > >> >> > Shouldn't Fedora at least wait until the dust settles in >> > >> > https://lkml.kernel.org/r/<20161123210256.31501-1-kilobyte@xxxxxxxxxx> >> > >> > and related, and equally lively, threads? >> >> For Rawhide, yes. But given the config option is most relevant for >> stable Fedora releases, it's worth enabling there separately if that >> is the decision that is come to. > > > I don't think it would be a bad idea to enable in rawhide and see how it > works out, from there it will trickle down as the stable releases get > rebased. While turning it on in theory shouldn't create a problem. I > honestly don't get warm fuzzies making such a change without at least some > time testing in rawhide. We are just a week or two away from 4.9 final now, > so it isn't a huge delay. The changes being proposed upstream are not even > in next yet, so it has some time to be shaken out before it would ever see a > stable release, though the feature would need to be enabled in rawhide for > testing as that happens. Yeah, normally I'd advocate for the flow-down method too. But at the moment, it's just flat out broken for 4.9. Jarod found a different issue with similar symbol commits causing parallel builds to fail in 4.9 as well. Which leads me to believe we should probably skip 4.9 unless this is a big enough issue to cause the final release to be held up. Given that, maybe it's best to wait for 4.10? josh _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
