Hi Brian, > So it seems there's 2 possible sticking points: code duplication, and > overall trend in the specs and implementation that might increase > duplication? > > To me, it seems like the duplication is minimal today, or at least, not > much as a result of anything in this patch proposal. There's some > repetition of 802.11 definitions already, but that's probably > orthogonal. Agree. > I have less understanding and foresight on the "trend" questions, > although David seems to somewhat agree in his response below -- that NXP > intends to handle modern security features in the host more and more, > which could indeed mean a bit more framing-related duplication. We'll see, but I don't _actually_ think this will significantly change the architecture here. In any case we can always kick the can further down the road. > > With this patch Mwifiex still a non-mac80211 implementation. > > Driver communicates with wpa_supplicant/hostapd via cfg80211 > > I think how driver/FW communicate each other is proprietary, I don't see a dependency with mac80211 here > > David, I may have pointed in the wrong direction by claiming "conflict" > with mac80211. I believe Johannes's concerns are in code duplication. Partially, yes, but also architecturally it should fit in. > Pretty much all other actively-maintained Linux WiFi drivers are based > on mac80211, so that we don't all have to implement the same frame > construction and parsing code. mwifiex is somewhat of an outlier in > actively adding new features while remaining a cfg80211-only driver. I'd say though that "actively maintained" part really is because full- MAC devices that are supported are very few now with Broadcom having essentially dropped out. I suspect there are other full-MAC chips and/or firmwares on the market, but few, if any, supported upstream. There's no particular reason this must be the case, it's just the way hardware architecture seems to be going. And as you said before, mac80211 is doing more and more offloads too, so the line ends up blurring from both sides. Which then again is part of my concern, if we blur the line from both sides we need to be even more careful to not grow into a parallel zone too much. > But for myself, I'm not even fully convinced mac80211-style stuff makes > sense here. Even just looking at the auth() stuff in patch 1, this > driver is far from a thin layer that allows mac80211 to handle the > 802.11 details. Just look at the 'priv->host_mlme_reg' and > HostCmd_CMD_MGMT_FRAME_REG stuff -- it seems that the simple act of > sending a single 802.11 frame requires opting into some FW-specific > command mask. I actually agree. > This feels "thick", like David mentioned above. This is kind of getting to the core of the thread: I, for one, don't think he made that argument. He just *claimed*, without much argument for that claim, that "Mwifiex is designed based on a "Thick FW" architecture." > > I think we are using standard cfg80211 commands. How it's handled > > between driver/FW is proprietary, it's carefully verified and shall > > not impact other features or break any architecture. > > David, repeating the "carefully verified" stuff doesn't really help the > subject at hand, and it's not really a technical argument either, Nor does "we are using standard cfg80211 commands", FWIW. That doesn't mean we need to think the architecture is good. Taking this argument to the extreme, it'd be entirely possible to put a (modified) copy of mac80211 into a driver and claim "we are using standard cfg80211 commands". It's a non-argument. And really here we get to the core of the issue: Brian, you have now mostly done the actual _technical_ analysis (and defence) of this patch that I was waiting for _David_ to do. johannes
