thoughts on modules-extra subpackage...

[Andy Gospodarek]

On Fri, Dec 02, 2011 at 01:51:09PM -0500, Josh Boyer wrote:
> On Fri, Dec 02, 2011 at 01:38:51PM -0500, John W. Linville wrote:
> > I'm sorry I missed the original discussion thread.  I was blinded by
> > my birthday and the Thanksgiving holiday. :-)  That, and I've been
> > chipping away to get the compat-wireless bits shaped-up for proper
> > Fedora integration...
> 
> Pfft... having a life is no excuse!  ;)
> 

I somehow missed it too and I don't even have a life! :-)

> > Actually, the latter is what brought modules-extra to my attention.
> > My changes cause ssb to not be built in the main kernel tree.
> > For some reason, ssb got added to mod-extra.list.  So, the combination
> > of modules-extra and my changes resulted in a broken build.  FWIW,
> > I think that fix is simple -- I don't think ssb should have been in
> > that list in the first place.
> 
> SSB was something we marked as 'why is this enabled at all??', so we
> went with the 'safe' route of moving it first.
> 

The ssb module is needed for b44 (wired) and b43 (wireless) drivers to
function properly.  That needs to get added back.

> > So that brings me to the first big concern...  Should we have _any_
> > hardware enablement included in the modules-extra package?  If so,
> > what is the cut-off?  Do we really want to diminish our out-of-the-box
> > hardware support for whatever benefit modules-extra provides?
> > Is there SMOLT data or something similar to justify the list of
> > modules being moved?
> 
> Nope, no smolt data.
> 

That is a bit troubling.  I definitely want as much hardware support as
possible to be available in Fedora.  I am particularly focused on
networking, so hopefully we do not move any reasonable wires or wireless
drivers out (which is essentially what happened when ssb was moved out).

> > Two other big chunks of the module-extras package are TCP congestion
> > control algorithms and network queueing disciplines.  These two
> > types of modules come immediately into play when someone is trying
> > to tune the performance of their networks.  If anything, we should
> > be encouraging their use, not making them more invisible.  So, I'm
> > wondering why these got put into the mod-extra.list file?
> 
> As I look at Fedora as a distro, those all got stuck there because the
> target user isn't someone doing power networking.  That's not to say we
> don't want those kinds of users, but unless NetworkManager is going to
> start doing mad tuning based on heuristics or something, most users
> aren't even going to know what those modules do.  So for the majority
> case, they are "extra".  People doing that kind of tuning are also
> likely familiar enough to be able to trivially install the subpackage.

As long as the know the package exists.  If they don't know that package
exists then it's a problem.

> > As for the stated benefits...  I'm skeptical of the security argument.
> > I mean, I can believe that a module could get accidentally or
> > inadvertantly loaded and then exploited.  I just think that closing
> > those holes is a better plan.  Also, I find the size argument
> 
> Yes, closing the holes is the end solution.  Until they're closed, we
> limit user's risk by not even installing them by default.  It's a 'limit
> risk' statement, not a solution.
> 
> > unconvincing as well.  I just don't think a couple of megs of storage
> > savings amounts to much these days, especially if you create confusion
> > or remove functionality in the process.  The cruft argument is the
> > most reasonable for at least some of the modules in the list, but
> > I'm not sure it is sufficient to justify the confusion and churn.
> 
> Honestly, my preferred solution is to just turn cruft off.  As in not
> build it at all.  However that goes against history a bit.
> 
> And yes, if we just turned stuff off we could probably eliminate the
> subpackage.  Then you get into weighing how "popular" a module has to be
> before you turn it back on though, which is never fun either.
> 
> > So anyway, just in case you were wondering about my opinion... :-)
> 
> Appreciate it.  It's never too late to give feedback.
> 
> josh
> _______________________________________________
> kernel mailing list
> kernel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/kernel