Search Linux Wireless

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

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

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux