thoughts on modules-extra subpackage...

[Josh Boyer]

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!  ;)

> 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.

> 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.

> 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 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