Re: [PATCH 1/1] mac80211: adding bss_config to low driver ops

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]