From: Thomas Monjalon <thomas@monjalon.net>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Ray Kinsella <ray.kinsella@intel.com>,
"Traynor, Kevin" <ktraynor@redhat.com>,
Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] [PATCH] doc: announce malloc virt2phys symbol removal
Date: Mon, 05 Aug 2019 17:13:19 +0200 [thread overview]
Message-ID: <3963110.nb0tCvxbkm@xps> (raw)
In-Reply-To: <CAJFAV8w3H9=v53NJ4i1c3wyLQHzc6h9itPaP5HcTHqaXHmnaMg@mail.gmail.com>
05/08/2019 17:05, David Marchand:
> On Mon, Aug 5, 2019 at 4:39 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 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 removal.
> >
> > 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 LTS."
> >
> > 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 suspect
> 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.
next prev parent reply other threads:[~2019-08-05 15:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 13:29 [dpdk-dev] [PATCH] doc: announce malloc virt2phys symbol removal David Marchand
2019-08-02 16:04 ` Burakov, Anatoly
2019-08-02 16:10 ` Jerin Jacob Kollanukkaran
2019-08-05 14:39 ` Thomas Monjalon
2019-08-05 15:05 ` David Marchand
2019-08-05 15:13 ` Thomas Monjalon [this message]
2019-08-12 10:42 ` Kinsella, Ray
2019-08-06 13:50 ` Andrew Rybchenko
2019-08-06 14:00 ` Ananyev, Konstantin
2019-08-08 9:32 ` [dpdk-dev] [PATCH v2] " David Marchand
2019-08-08 15:44 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3963110.nb0tCvxbkm@xps \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ktraynor@redhat.com \
--cc=ray.kinsella@intel.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.