Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/30/2016 03:19 PM, Justin Forbes wrote:
> On Wed, Nov 30, 2016 at 4:33 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx <mailto:jwboyer@xxxxxxxxxxxxxxxxx>> wrote:
> 
>     On Wed, Nov 30, 2016 at 5:29 PM, Paul Bolle <pebolle@xxxxxxxxxx <mailto: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 <mailto: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.
> 
> Justin
> 
> 

I'm not opposed to turning it on but I'm a little bit wary
of this causing unexpected problems for users. From
experience, how likely is it that a module passes the version
checks but something else has changed such that it no longer
works? Even if we can't officially support 3rd party modules,
I'd like to not make it too much worse within reason.

Thanks,
Laura
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux