Hi Marcel, > just to document the irony here. Two or three years ago at OLS, Kyle and > Greg were making fun of Ubuntu merging its 5th wireless stack into their > kernel. Now the staging crap is doing exactly the same. :) Actually, last I counted it was already 7 or 8 stacks in staging _only_. This (and the other patch) will add two more. Not to mention that of course we already have something like two and a half stacks in the kernel tree (mac80211, in hostapd, and libipw [former ieee80211]). > At some point I like to see some proper future development/cleanup > planning for drivers in the staging area. Dumping stuff in there doesn't > help at all and personally I don't see anybody cleaning up this mess. Which is why, for all wireless "drivers" but agnx and stlc45xx in staging I have requested that the linux-wireless list not be copied on any of the "patches" for those drivers. All of these other drivers are, in my opinion, entirely pointless and need to be rewritten from scratch using the current infrastructure. No amount of cleanup will help -- there is a _fundamental_ design difference. Compare ar9170 (rewritten) with otus (vendor) for an example. Mind you, there don't seem to be many developers capable of doing that, and therefore all these drivers will never "make it". All wireless patches in staging, that haven't been proposed by people very familiar with the wireless code, have so far been in the "brain-dead cleanup" category. > Do we have an option to taint the kernel when a staging driver is used. > Similar to what we do with binary drivers or ndiswrapper? It's already doing that. FWIW, I trust many of those staging drivers a lot _less_ than, for instance, Broadcom's binary-only wl.ko driver. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
