From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 3E3559AB5 for ; Tue, 1 Mar 2016 10:44:00 +0100 (CET) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 7CABD627C0; Tue, 1 Mar 2016 09:43:59 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-7-140.ams2.redhat.com [10.36.7.140]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u219hwPm009059; Tue, 1 Mar 2016 04:43:58 -0500 To: =?UTF-8?Q?Wojciech_=c5=bbmuda?= , "Iremonger, Bernard" References: <1455208630-21710-1-git-send-email-woz@semihalf.com> <8CEF83825BEC744B83065625E567D7C219FB4223@IRSMSX108.ger.corp.intel.com> From: Panu Matilainen Message-ID: <56D5645D.3050304@redhat.com> Date: Tue, 1 Mar 2016 11:43:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 01 Mar 2016 09:43:59 +0000 (UTC) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3] af_packet: make the device detachable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 09:44:00 -0000 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 >