On 02/18/2016 01:14 PM, Johannes Berg wrote:
On Thu, 2016-02-18 at 12:59 -0800, Ben Greear wrote:
Oh. In that case, what if this happens:
wiphy created and init
vdev created, vht copied from wiphy
....
wiphy vht info changes? Can this ever happen? I'm thinking maybe
when
a user uses 'iw' to set the rx/rx chainmask on a phy? Possibly
nasty debugfs hacks that have worked so far?
Ah, but I don't think this is something that's supposed to happen.
Then again, there were some people talking about this last week, with a
use case that seemed valid (shared antennas and reconfiguration or so),
but we can require that to cause some action to propagate it. My gut
reaction was to just re-register the entire wiphy, but that may be too
big of a hammer.
In any case, I think this isn't something we really need to consider
too much. If there are bugs in this area then we'll fix them one way or
another (or perhaps we'll just never find them since I don't expect
many people to use this functionality).
So, I think it should be more like:
if (vdata->have-user-config) {
return sdata->user_config_vht & sdata->wiphy->vht;
}
else {
return sdata->wiphy->vht;
}
Point of the above 'code' is that we do not want to ever have
duplicate state (ie, a copy of wiphy->vht in sdata->vht, because then
they can get out of sync. But, we can have a set of over-ride data
in sdata, and since we logically AND that with wiphy data, then we
should never exceed the capabilities of either sdata or wiphy.
That make sense?
Yeah, it does, at least if you assume that the capabilities can
actually change. We assume they don't though, hostapd/wpa_s for example
will never re-query them after startup.
Restarting supplicant, even if it came to that, might be less
of an issue than having to re-create the vdev to have it grab
proper new settings from the wiphy...
I also don't like the whole "call a function to get the capabilities"
not much more than what you have now in the code, since then we'll have
to deal with allocations (or stack memory) for the data we want and it
just generally makes the code using the capabilities much more complex
(for a pretty fringe use case.)
I'd much rather have the data structure that we can use as today
without additional hoops to jump through, just possibly "redirecting"
it for the use cases you have in mind.
Well, it would be easy enough to make a method that updated an vdev/sdata->vht from
wiphy, so could just call that as needed (ie, when certain things set or
are changed by wiphy).
Ok, the details of mac80211 have leaked out of my skull since the
start of this thread...I'll see if I can make a stab at implementing
this proposal. But, likely it will be a bit, as I'm swamped with
other things at the moment. If someone else is interested in trying
this, then of course be my guest!
Looked like Cedric Debarge had a similar idea, I've pointed him to this
thread (as you probably saw.)
Yeah, I tried to read the patch when first posted, but I am not
sure I understand what he is trying to do.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
