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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/kernel _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
