On Fri, 2014-11-14 at 11:10 -0600, Dan Williams wrote: > On Fri, 2014-11-14 at 10:02 -0600, Dan Williams wrote: > > On Fri, 2014-11-14 at 16:02 +0900, Marcel Holtmann wrote: > > > Hi Dan, > > > > > > >>>> I've updated wireless code on RHEL and get complain that now > > > >>>> cfg80211 and rfkill modules are loaded on machines that do not have > > > >>>> wireless hardware. Modules are auto-loaded because NetworkManager > > > >>>> send > > > >>>> nl80211 messages to check if there are wireless devices in the > > > >>>> system. > > > >>>> > > > >>>> Hence my question, can we revert commit fb4e156886ce > > > >>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ? > > > >>> > > > >>> Realistically, we can't revert it, but only remove the > > > >>> MODULE_ALIAS_GENL_FAMILY() line. > > > >>> > > > >>>> Auto loading nl80211 does not seems to be necessary, if there are > > > >>>> wireless devices nl80211 will be loaded anyway. > > > >>> > > > >>> Maybe other applications would like to see an empty list of devices? > > > >>> But > > > >>> OTOH, if they're robust at all, they have to cope with kernels not > > > >>> even > > > >>> compiled with nl80211, so I guess for me I don't really see a big > > > >>> difference in whether the module alias exists or not. > > > >> > > > >> auto-loading cfg80211 module when userspace requests nl80211 netlink > > > >> family is exactly the right thing to do. Systems compiled without > > > >> nl80211 support and systems with no wireless device attached are two > > > >> different things. > > > >> > > > >> Someone can fix NetworkManager to not send nl80211 messages or just > > > >> plain accept that cfg80211 will be loaded. > > > > > > > > NM uses nl80211 initially to determine whether *any* ethernet-type > > > > interface (a) is actually WiFi, and (b) should be driven by nl80211 or > > > > WEXT. Because of the variety of drivers (both in-kernel and > > > > out-of-kernel) and the variety of kernel versions (NM supports back to > > > > early 3.x series) we cannot rely on specific behavior. > > > > > > > > So given an ethernet-type interface, how do we determine that it is > > > > wifi? > > > > > > > > DEVTYPE=wlan - not always reliable due to driver and kernel versions > > > > > > if anybody wants to write kernel patches, then making sure that all > > > wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason > > > a driver does not do it, that is a bug. > > > > Yeah, that's nice, and should be done. It seems a number of drivers > > don't have it. Obviously everything mac80211 does, and it seems we're > > left with: > > > > 1) legacy drivers that only support WEXT (airo, etc) > > 2) out-of-tree drivers (wl.o and various realtek/ralink stuff?) > > > > So it seems that new best practice is: > > > > a) if DEVTYPE=wlan, hit up nl80211 to determine whether the interface > > supports nl80211 or WEXT (minimal cfg80211 ports like ipw2x00 don't > > actually support nl80211 at all and must use WEXT) > > > > b) if DEVTYPE is missing, WEXT can be tried if it is available > > > > c) treat interface as 'ethernet'; out-of-tree WiFi drivers may end up > > here but that is life > > > > Does that sound valid to everyone else? > > Potential NM fix filed at: > > https://bugzilla.gnome.org/show_bug.cgi?id=740131
Merged after review and backported to 0.9.10 too. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
