From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3493717829051924515==" MIME-Version: 1.0 From: Denis Kenzior Subject: Re: [PATCH 1/7] extended support for LTE and NR. Some minor fixes. part 1 of 7 Date: Wed, 19 Sep 2018 16:45:26 -0500 Message-ID: In-Reply-To: <3362056b-a4d5-d51f-7c23-8e1fef2c130a@jolla.com> List-Id: To: ofono@ofono.org --===============3493717829051924515== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 { > =C2=A0=C2=A0=C2=A0 OFONO_GPRS_AUTH_METHOD_ANY =3D 0, > =C2=A0=C2=A0=C2=A0 OFONO_GPRS_AUTH_METHOD_NONE, > =C2=A0=C2=A0=C2=A0 OFONO_GPRS_AUTH_METHOD_CHAP, > =C2=A0=C2=A0=C2=A0 OFONO_GPRS_AUTH_METHOD_PAP, > }; So you already made life very hard for yourself ;) > = > (ANY =3D 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 --===============3493717829051924515==--