FYI: vendor specific nl80211 API upstream

FYI: vendor specific nl80211 API upstream

[Johannes Berg]

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

Re: FYI: vendor specific nl80211 API upstream

[Denis Kenzior]

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

Re: FYI: vendor specific nl80211 API upstream

[Johannes Berg]

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

Re: FYI: vendor specific nl80211 API upstream

[Denis Kenzior]

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