On Wed, Nov 30, 2016 at 6:19 PM, Justin Forbes <jforbes(a)redhat.com> wrote:
On Wed, Nov 30, 2016 at 4:33 PM, Josh Boyer
<jwboyer(a)fedoraproject.org>
wrote:
>
> On Wed, Nov 30, 2016 at 5:29 PM, Paul Bolle <pebolle(a)tiscali.nl> 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@angband.pl>
> >
> > 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