Ping. Review needed. Packet range patch needs this. We have deprecation in place already. This patch set makes deprecation more explicit than it's today. With this deprecation is off by default, and user can turn it on. Today, deprecation is on by default and there's no way to turn it off.
It's another discussion, if deprecation should be removed all together. We don't decide that on this patch set. This set makes it possible to control it. I think majority of the people think that it's good to offer the flexibility. -Petri > -----Original Message----- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Savolainen, Petri (Nokia - FI/Espoo) > Sent: Monday, April 24, 2017 2:06 PM > To: Maxim Uvarov <maxim.uva...@linaro.org> > Cc: lng-odp@lists.linaro.org > Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > > Ping. Review needed. Are we ready to merge? This should work fine with > distros as explained two weeks ago. > > > -Petri > > > > -----Original Message----- > > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > > Sent: Thursday, April 13, 2017 6:02 PM > > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- > > labs.com> > > Cc: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>; lng- > > o...@lists.linaro.org > > Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > > > > On Thu, Apr 13, 2017 at 9:07 AM, Savolainen, Petri (Nokia - FI/Espoo) > > <petri.savolai...@nokia-bell-labs.com> wrote: > > > > > > > > >> -----Original Message----- > > >> From: Dmitry Eremin-Solenikov > > [mailto:dmitry.ereminsoleni...@linaro.org] > > >> Sent: Thursday, April 13, 2017 1:57 PM > > >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia- > bell- > > >> labs.com>; lng-odp@lists.linaro.org > > >> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > > >> > > >> On 13.04.2017 10:33, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: Dmitry Eremin-Solenikov > > >> [mailto:dmitry.ereminsoleni...@linaro.org] > > >> >> Sent: Wednesday, April 12, 2017 3:11 PM > > >> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia- > > bell- > > >> >> labs.com>; lng-odp@lists.linaro.org > > >> >> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > > >> >> > > >> >> On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > >> >>> > > >> >>> > > >> >>>> -----Original Message----- > > >> >>>> From: Dmitry Eremin-Solenikov > > >> >> [mailto:dmitry.ereminsoleni...@linaro.org] > > >> >>>> Sent: Wednesday, April 12, 2017 2:32 PM > > >> >>>> To: Petri Savolainen <petri.savolai...@linaro.org>; lng- > > >> >>>> o...@lists.linaro.org > > >> >>>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > > >> >>>> > > >> >>>> On 30.03.2017 16:58, Petri Savolainen wrote: > > >> >>>>> Replaced ODP_DEPRECATED macro (which was based on GCC > > __attribute__) > > >> >>>> with > > >> >>>>> compiler independent mechanism to control if deprecated API > > >> >> definitions > > >> >>>> are > > >> >>>>> visible to the application. ODP_DEPRECATED_API can be used both > > in > > >> >>>> application > > >> >>>>> and implementation to check if deprecated APIs are enabled. By > > >> default > > >> >>>> those are > > >> >>>>> disabled. Implementation may optimize the normal (new API) code > > >> path. > > >> >>>>> > > >> >>>>> ODP_DEPRECATE() macro is used to rename definitions, so that > data > > >> >>>> structure > > >> >>>>> sizes are equal on both options. This enables implementation to > > >> serve > > >> >>>> both > > >> >>>>> options with a single library (if it wishes to do so). > > >> >>>> > > >> >>>> My main question remains as it was before: is it possible for > the > > >> >>>> distribution to supply (unoptimized) ODP binary and headers and > > then > > >> >> for > > >> >>>> the application to select if it builds with or without > deprecated > > API > > >> >>>> using that binary/headers? > > >> >>> > > >> >>> > > >> >>> Yes. This patch set keeps the same struct fields/etc for both > modes > > - > > >> >> only the names are scrambled (with __deprecated_ prefix) when > > >> deprecated > > >> >> APIs are not supported (the default). > > >> >> > > >> >> If so. Consider I have built and installed ODP headers & binary > > built > > >> >> with --enable-deprecated-api. > > >> > > > >> > So, you have built and installed the implementation with --enable- > > >> deprecated-api. This means that applications using this install, see > > >> deprecated APIs. A distribution decides which way it supports ODP, > with > > or > > >> without deprecated stuff. The default in our (odp-linux) configure is > > >> without, to minimize confusion and promote the new API definitions > > which > > >> should be always better for application than the old ones. > > >> > > > >> > > >> I was advocating for binary distributions and developers using > packages > > >> from those distributions. And for those distributions providing > > _single_ > > >> binary version of ODP. > > > > > > Obviously, a distribution would select which ODP API versions are > > supported, and if those versions include deprecated APIs or not. > > Deprecation is feature of API spec and thus header files. A header file > > cannot be in both modes at the same time. E.g. a struct either has a > field > > e.g. int foo or int _deprecated_foo, but not both at the same time. > > > > > > A single library can support both modes since struct sizes are the > same > > (_deprecated_foo is left with default values since application does not > > read/write it). > > > > > > Now, if a distribution dictates that deprecated APIs are supported, an > > implementation delivers headers with deprecated stuff and a library that > > supports those. The same happens in the opposite case (headers without > > deprecated stuff and an library that supports those). Depending on > > implementation the library binary may be same or different. Distribution > > does not care, since it needs to store headers and pairing libs for > those > > in any case. > > > > > > We do not guarantee binary compatibility over different API versions. > > Application, API headers and implementation lib need to be on the same > API > > version - with or without deprecated stuff. > > > > Good summary. Having ODP part of a distro simply means that someone > > has installed it in the library catalog associated with that distro > > and configured it however they wished. At that point it's either part > > of the default install or can be installed with apt-get, yum, etc. > > > > What gets installed are the include files that allow applications to > > compile/link against that ODP installation, and the associated .so > > files that provide the runtime support for these apps. If I look on my > > Ubuntu 16.10 system I see /usr/include/clang and under that are > > several different release options (3.6, 3.6.3, 3.8, and 3.8.1 in my > > case). Similarly there is a /usr/lib/clang/ with the individual > > releases under it. ODP is no different. I'd expect there to be > > /usr/include/odp/<release> and /usr/lib/odp/<release> directories > > present. At that point it becomes a business decision, as to which > > releases / configurations a given distro offers. > > > > So if an application is built to run on ODP release X then it needs > > the libraries associated with release X to be available to it. If the > > distro also offers release Y and Z that's fine, but the app still will > > continue to run just fine as long as release X is still available. How > > long that is is an LTS consideration because at some point release X > > will no longer be supported and the application will have to move to a > > currently supported release. When it does that it needs to do two > > things: > > > > 1. Ensure that it's not using any APIs that are no longer present in > > the new release > > 2. Recompile against the new release > > > > Given that it's had years to prepare for step 1, I don't think it's > > unreasonable to assume that we have no need to support deprecated > > APIs, so distros aren't going to bother with having deprecated APIs > > being part of newer releases. If we wanted to continue their support > > it would be simpler to just continue the LTS for release X. > > > > Again, deprecation is a rare event and is mainly a documentation / > > communication / planning matter, not something that needs a lot of > > infrastructure support. > > > > > > > > -Petri > > > > > >
