[dpdk-dev] [PATCH v3 5/6] doc: remove dpdk iova aware notice

[Richardson, Bruce]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, October 25, 2017 10:46 AM
> To: santosh <santosh.shukla at caviumnetworks.com>
> Cc: dev at dpdk.org; olivier.matz at 6wind.com; jerin.jacob at caviumnetworks.com;
> hemant.agrawal at nxp.com; Burakov, Anatoly <anatoly.burakov at intel.com>
> Subject: Re: [dpdk-dev] [PATCH v3 5/6] doc: remove dpdk iova aware notice
> 
> Hi Santosh,
> 
> 24/10/2017 07:06, santosh:
> > Hi Thomas,
> >
> >
> > On Tuesday 24 October 2017 01:59 AM, Thomas Monjalon wrote:
> > > 20/10/2017 14:31, Santosh Shukla:
> > >> Removed dpdk iova aware ABI deprecation notice, and updated ABI
> > >> change details in release_17.11.rst.
> > >>
> > >> Signed-off-by: Santosh Shukla <santosh.shukla at caviumnetworks.com>
> > >> Acked-by: John McNamara <john.mcnamara at intel.com>
> > >> ---
> > >> --- a/doc/guides/rel_notes/deprecation.rst
> > >> +++ b/doc/guides/rel_notes/deprecation.rst
> > >> -* eal: An ABI change is planned for 17.11 to make DPDK aware of
> > >> IOVA address
> > >> -  translation scheme.
> > >> -  Reference to phys address in EAL data-structure or functions may
> > >> change to
> > >> -  IOVA address or more appropriate name.
> > >> -  The change will be only for the name.
> > >> -  Functional aspects of the API or data-structure will remain same.
> > > Sorry, this series cannot be applied as is because it is breaking
> > > more than EAL API. The API of mbuf and mempool are also changed.
> > > We need to choose one of these three options:
> > > 	1/ accept to break all API in 17.11
> > > 	2/ postpone the whole series to 18.02
> >
> > Theme of series is to make dpdk iova aware so I would prefer option 1)
> or 2).
> > However I have no strong opinion on this topic.
> > Lets get more opinion from others about option 1/2/3.
> >
> > > 	3/ rename only EAL API in 17.11 and postpone mbuf/mempool
> 
> After discussing with Olivier it appeared there is a fourth solution.
> We should not break any API (EAL, mbuf, mempool).
> 
> I would like to merge these changes in RC2, but keeping compatibility with
> old names:
> - When you rename a function or a type, you can define a macro for the old
> name, alias the new name.

Note: using a macro doesn't prevent the ABI being broken if you rename a public function. You'll need to use function versioning too.