From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by dpdk.org (Postfix) with ESMTP id A90DD9AB7 for ; Wed, 2 Mar 2016 12:47:20 +0100 (CET) Received: by mail-vk0-f47.google.com with SMTP id k196so199640296vka.0 for ; Wed, 02 Mar 2016 03:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=r8dFAaHCmeS23YjmWncdSEoc5wVMjfY5AerUIkGKNnU=; b=ypz6lbuxlf3+en0yw10rcuZ4KkzT30mTXvgI4VwY5UiG5rqfNjHI+UK7cjOcg7NSnc wJfcthcHLa7gxBAjgMFFhig5QD0BWKgFGvsXTCnI79CEvJHeUZyjBQBC7++/VGJHcUY/ Kl3kR8t0HTOmLhqVPZFS7/mFvQ7dfW7TLZpFYGi/WYJp7qzLwWNCbdLg1p6Jtftue20a 7rpfMumlonmp1QnZUTvkX2uYA0r8qXdWsbsZxoOq8F7uYuDbZs/hxs8AEp3tYqwEKVoB iimt3c3+E7d3C/1ibQQRdG2CyEsZjQ0SRWXijy+q8tN9ueWVmghu6XNm+uoIoZhZagjQ 6m4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=r8dFAaHCmeS23YjmWncdSEoc5wVMjfY5AerUIkGKNnU=; b=P86NSiIxZa6nBHVJ8dqXFjYHQEGswxke7hGWLbcJeGIdsPoNnMewIcFPdONDCFFL+b 2pBOWToy5VZUrgGrZ/zCj14arSfFRYmRhbYBRFCWQhFNVgx8Exq5Q+wl2Z4dteeN91V6 +i38fEc7+ntn8lq9/UIBrytfT72Y6XbDfyDVyeO4o2m0OmAOMAmgwrF3AC/l7ukJCud4 /bM61oXEHmQFv9lcE+I1I9RKoVAv47eQPmMt58fEJGycTF0S5f/nFvkgzlB7l1g+fyD9 PPHLyQ/S0vN1ZKxKhHSndnlZ3gGwUtDkRoLWd68yeXzQXBtPMO/vojImPCDrOJ1oT3MH N7bA== X-Gm-Message-State: AD7BkJJVXxR9qEEmMLfr0sJimouHgMupUNP/UuPrPljQOA2B1iLR6ze08oCk7qRxDfvzMwx4OxtB5XQtaTV81g== MIME-Version: 1.0 X-Received: by 10.31.42.198 with SMTP id q189mr16873756vkq.60.1456919240182; Wed, 02 Mar 2016 03:47:20 -0800 (PST) Received: by 10.159.37.73 with HTTP; Wed, 2 Mar 2016 03:47:20 -0800 (PST) In-Reply-To: <56D5645D.3050304@redhat.com> References: <1455208630-21710-1-git-send-email-woz@semihalf.com> <8CEF83825BEC744B83065625E567D7C219FB4223@IRSMSX108.ger.corp.intel.com> <56D5645D.3050304@redhat.com> Date: Wed, 2 Mar 2016 12:47:20 +0100 Message-ID: From: =?UTF-8?Q?Wojciech_=C5=BBmuda?= To: Panu Matilainen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 02 Mar 2016 11:47:20 -0000 Hi Panu, >I think its okay to remove without going through the deprecation process. > just drop the accidentally exported symbol from the 2.0 definition. Well, this is what I've done so far. I'm going to post v4 patch modifying release_16_04.rst instead of release_2_3.rst, then. Thank you for sharing your opinion on this topic. Wojtek 2016-03-01 10:43 GMT+01:00 Panu Matilainen : > On 02/29/2016 08:22 PM, Wojciech =C5=BBmuda 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 A= BI > 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 thro= ugh > 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 changin= g > 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 >> >