[dpdk-dev] [PATCH] doc: announce malloc virt2phys symbol removal
ray.kinsella at intel.com
Mon Aug 12 12:42:57 CEST 2019
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Monday 5 August 2019 16:13
> To: David Marchand <david.marchand at redhat.com>
> Cc: dev <dev at dpdk.org>; Burakov, Anatoly <anatoly.burakov at intel.com>;
> Richardson, Bruce <bruce.richardson at intel.com>; Kinsella, Ray
> <ray.kinsella at intel.com>; Traynor, Kevin <ktraynor at redhat.com>; Stephen
> Hemminger <stephen at networkplumber.org>
> Subject: Re: [dpdk-dev] [PATCH] doc: announce malloc virt2phys symbol
> 05/08/2019 17:05, David Marchand:
> > On Mon, Aug 5, 2019 at 4:39 PM Thomas Monjalon <thomas at monjalon.net>
> > > 02/08/2019 15:29, David Marchand:
> > > > This symbol has been deprecated for quite some time.
> > > > Let's drop it in the next release.
> > > > ---
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > +* eal: The ``rte_malloc_virt2phy`` function has been deprecated
> > > > +and replaced
> > > > + by ``rte_malloc_virt2iova`` since v17.11 and will be removed
> in DPDK 19.11.
> > >
> > > For this patch and another one about removing
> > > rte_cpu_check_supported(), I have a general comment on the date of
> > >
> > > As was stated recently in the contribution guide:
> > > http://git.dpdk.org/dpdk/commit/?id=7abe4a24cc
> > > "Deprecated APIs are removed completely just after the next
> > >
> > > The idea behind this policy is to avoid removals during LTS
> > > releases, in order to have at least one release before X.11 LTS for
> > > end users to prepare replacing the usage of the removed API.
> > >
> > > Does it make sense to postpone any API removal after 19.11?
> > Those symbols have been marked as deprecated for a long time.
> > Users had to either disable Werror or they actually migrated to the
> new apis.
> > If they chose the lazy way of not migrating to the new apis, I
> > they forgot about it and/or they won't look at the release notes.
> Yes I agree.
> That's why they can be surprised when hitting the removal.
> Avoiding this removal in LTS release is one more care for the lazy
> users. The question: is too much caution?
> > I don't particularly have a problem with waiting for 20.02, those are
> > easy to remove anyway.
My 2c is that if they are have signalled as deprecated since v17.11.
They are fair game for removal at this point.
More information about the dev