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.
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.
> 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.)
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
