Re: [PATCH 1/7] extended support for LTE and NR. Some minor fixes. part 1 of 7

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Hi Slava,

>> I understand that! It makes things easier for you guys.
>>
>> But we had to avoid certain compile-time dependencies in ofono, and a 
>> straightforward (and perhaps the only) way to achieve that was to use 
>> binary plugins. For us plugin API is not subject to change (plugins 
>> don't necessarily get upgraded together with ofono), meaning more 
>> changes between our fork and upstream in case if upstream breaks it, 
>> more maintenance work and more room for errors. Obviously, I would 
>> like to keep differences to a minimum.

So I sympathize, but really it might also be a hint to finally start 
getting things upstream.

>>
>> I'm just humbly asking - if there's a way to keep plugin API backward 
>> compatible, please do it that way. There is at least one person in the 
>> world who would appreciate it.
>>

The problem is, the next time this comes up there may be no way to avoid 
it...  Or we break binary compatibility inadvertently.  It is just not 
something we're going to be looking out for.

> 
> Actually, in our fork we have already modified enum 
> ofono_gprs_auth_method and that's what we have there:
> 
> enum ofono_gprs_auth_method {
>      OFONO_GPRS_AUTH_METHOD_ANY = 0,
>      OFONO_GPRS_AUTH_METHOD_NONE,
>      OFONO_GPRS_AUTH_METHOD_CHAP,
>      OFONO_GPRS_AUTH_METHOD_PAP,
> };

So you already made life very hard for yourself ;)

> 
> (ANY = PAP_CHAP, and don't ask me why we added new values to the 
> beginning of the enum - it was before we started using binary plugins). 
> I would be more than happy if upstream started to use the same enum!
> 

That assumes that we should support your METHOD_ANY thing.  I've not 
heard any good arguments for that yet...

Regards,
-Denis