On Fri, 2024-03-22 at 18:06 -0700, Brian Norris wrote: > We appreciate it's well tested, but testing is still orthogonal to the > architectural questions. Architectural questions are important because > they affect the future maintainability of the mainline Linux wireless > stack. If the assumption is that *either* a driver is a cfg80211 driver > (with firmware-MLME, etc.) or a mac80211 driver (with host MLME), then > your series is breaking those assumptions. Maybe, maybe not, actually. The auth command _is_ somewhat special in that it mostly hands stuff down from userspace via cfg80211, but does require sending frames. As long as you don't have full offload, at least. The way I see it, the issue here isn't necessarily the fact that this uses the auth command (and then requires assoc, of course), but that we see here this is "growing" towards a more mac80211-like model, with the code duplication (albeit little that it is today) implied by that. To me, it seems like the firmware is moving into the "oh we can't do all _that_ in firmware" territory, and that brings it closer to mac80211. At the same time, as you say, mac80211 is doing more and more offload capability, so it seems like apart from "today the firmware requires an assoc command rather than assoc frame processing in the host", it's actually not _that_ far apart any more! Now that may be an issue in the short term, but I wouldn't be surprised at all if desiring to implement FILS and other new features in this space would make the driver move to assoc frame processing in the host as well, because it's getting more and more complex, just like auth. At which point - yeah the APIs are still significantly different, but again we'd end up implementing something that exists in mac80211 today and taking it into mwifiex? > It may be harder to add > future additions to the mac80211 stack [*], if we have to add new > concerns of a non-mac80211 implementation in the mix. Not sure that makes a difference for mac80211 in itself, obviously changes in this space would then affect mwifiex, but that shouldn't be much of an issue. I'm less worried about this individual patch than what it says about the direction this driver and firmware are taking, and I fear we'll end up in a situation where over time this driver actually gets to a point where it should be using mac80211, but because it's such a piece-meal affair (auth frames now, etc.) and large architectural change, they'd never actually do that. To be fair, that might also require firmware API changes in some way. I used to think that was something we should never require, but I'm not so sure now any more - certainly we've changed our (Intel) FW API in support of Linux architecture many times, and overall that's for a better product (on Linux at least.) Also: David, I'd appreciate if you actually took this discussion seriously; so far you've not really contributed any technical arguments. johannes
