On Mon, 2012-01-02 at 16:38 +0200, Eliad Peller wrote: > > I have a more fundamental issue/thought though, but it's hard to put > > into words... let me start from what I thought we might want. > > > > I think with the auth/assoc rework I'm planning, we will want to add the > > station to the driver before auth, in NONE state. To implement that with > > the current state, that means changing all drivers that want the station > > in assoc state only. > > > > So to solve this more cleanly, I thought we could hijack the station > > state callback (this patchset) and call sta_state even when the station > > isn't uploaded yet. > does it really make sense to notify the driver about state transitions > of station it doesn't know? Well, no, but the station transition would let it know in a way. It would go from not existing to NONE state. > > Basically my idea was that new drivers that use the station state > > callback can add/remove stations based on the state callback. > > > > The mac80211 backward compatibility implementation would take the state > > call and call sta_add() if the station goes into ASSOC state (this > > actually depends on the interface type, but that's easy to do.) > > > > This means we need better error handling for state transitions in a lot > > of cases, but I think that's doable. > i guess we should always delete the station on error? otherwise, the > station state becomes unclear. In most cases we would, yes. > if sta_state will be allowed to return an error, instead of adding a > new backward compatibility implementation to mac80211 we can just > change all the current drivers to register for sta_state(), and > operate on auth->assoc and assoc->auth transitions instead of > sta_add/sta_remove. Right, that's the alternative, but it would be easier to add the code in mac80211 I think? And if we add a "NOT_EXIST" state we can completely make sta_add/sta_remove be only there for drivers that don't need more advanced state? johannes -- 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
