Hi Johannes,
On 05/29/2019 04:09 AM, Johannes Berg wrote:
On Tue, 2019-05-28 at 12:36 -0500, Denis Kenzior wrote:
I'm guessing that you guys considered and rejected the idea of pushing
these out to a separate, vendor specific genl family instead?
We do actually use that internally (though mostly for cases where we
don't have a cfg80211 connection like manufacturing support), but vendor
commands are there and people do like to use them :-)
And herein lies the danger. If you make it too easy to add vendor APIs,
there's no incentive for the vendors to do anything else. In the end
this all becomes a mess for userspace to deal with.
One idea off the top of my head is to introduce a concept of
'experimental' APIs in NL80211, ones that are not guaranteed to be ABI
stable going forward. Specifically for dealing with such 'vendor' APIs.
The semantic difference might be subtle, but I think the effect will
be drastically different. E.g. people will approach this more seriously
and you will get more people reviewing the API.
The idea with formalizing this is that they actually get more
visibility, and I hope that this will lead to more forming of real
nl80211 API too.
What about ABI guarantees (to tie it in with the discussion above) ?
If the vendor wants to change their API, can they? Are NL80211 APIs
stable unless they are vendor APIs?
Anyhow, speaking from experience with oFono, which has to deal with a
bazillion of wwan modem vendors, I suspect that the opposite will
actually happen. Any time we let through a vendor API, the vendor lost
any interest in generalizing it further. And it becomes a huge pain to
implement a proper generic one later. I get that there are cases where
something just cannot be generalized. In that case it belongs on a
separate genl family (or whatever) altogether.
So I would highly encourage you to reconsider this decision and
deprecate vendor APIs altogether. If someone really cares, they can
implement their own genl family. It is really not that hard. And then
they control the API, API stability policy, etc.
Regards,
-Denis
