Hi all,
FYI - at the discussions in Prague we decided to let some vendor
specific nl80211 API go upstream, and I've just documented the expected
rules here:
https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
I guess this will be fine-tuned as we go along, but wanted all to be
aware.
johannes
Hi Johannes,
On 05/28/2019 06:51 AM, Johannes Berg wrote:
> Hi all,
>
> FYI - at the discussions in Prague we decided to let some vendor
> specific nl80211 API go upstream, and I've just documented the expected
> rules here:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
>
I'm guessing that you guys considered and rejected the idea of pushing
these out to a separate, vendor specific genl family instead?
Regards,
-Denis
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 :-)
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.
johannes
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