On 02/29/2016 08:22 PM, Wojciech ?muda wrote:
> Hi Bernard,
>
>> Does making rte_pmd_af_packet_devinit local result in an ABI breakage?
> If someone uses it in their app, they'll be forced to change it.
> However, as this function is not intentionally public and there is API
> to create devices that finally calls rte_pmd_af_packet_devinit(), I'm
> not sure if any special caution is needed here.
Yeah this is a bit of a gray area. Strictly speaking it certainly is an
ABI break, but given that the function is documented as internal-only
and there's a proper, public way to create the device, there's no good
excuse for anybody to be using it. I think its okay to remove without
going through the deprecation process.
>
>> Should the DPDK_2.0 structure be kept and a DPDK_2.3 structure added?
> Should it be just `DPDK_2.3 { local: *} DPDK_2.0`? Doesn't inheritance
> of DPDK_2.0 make the symbol also global in 2.3?
Since there are no symbols being exported I dont see any point in
changing the version, just drop the accidentally exported symbol from
the 2.0 definition.
- Panu -
>> A deprecation notice may need to be added to the
>> doc/guides/rel_notes/deprecation.rst file.
> As far as I understand, deprecation.rst is used to announce something
> will be removed in the future release. Changes already done should be
> moved from deprecation.rst to the release's .rst file. At least, this
> is what I see in commit logs. If this change should be announced in
> deprecation.rst, does this mean there should be another patch in the
> future (after 2.3 release?) making this function static? And that
> future patch will add DPDK_2.3 structure in the map file?
>
> Thank you for your time,
> Wojtek
>
