On Thu, 2007-10-18 at 20:46 +0200, Tomas Winkler wrote: > > /** > > * DOC: BSS Status changes > > * > > * Describe what is expected of driver here > > */ > > > > We'll do Thanks. One of these days I'll get all the kernel-doc stuff sorted out and actually post the mac80211 book for inclusion. > > This seems pretty ad-hoc to me. I think it'd be better to have them all > > in one structure and use just a single 'changed' parameter instead of > > having an extra one in the erp info. I would also use a 'flags' > > parameter instead of 'assoc' and then roll CTS protect and short > > preamble into those flags. > > > The bits in flags are possible just sometimes you need to pass a value > such as assoc id > or queue num so it will be a little mess. Oh right. I guess we need good docs as to which "changed" flag implies which fields have actually changed since things like "assocation status changed" implies that the AID is new *and* the "associated" flag is changed too. On the other hand, maybe we should aim for some redundancy and have a changed flag for each struct member and each flag? Hmm. Thinking about this a bit more, the AID can actually change when the association status didn't change, in the case where we associated to another AP. Though we actually tell the driver that we disassociated first, right? That makes me think we should maybe also make the BSSID part of this call structure instead of having it in if_conf. Hmm. > Yes we can have both valid and change bitmap to lower that burden from > form driver. Note that embedding the info might be a lot of work. Then again it might just be some code shuffling and simplification. I haven't looked at it, from the stuff I see here I just think it'd be worth it. Your tradeoffs are probably different than mine though and in either case such a callback is an improvement over current behaviour. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
