From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 48B20A2EDB for ; Tue, 1 Oct 2019 15:19:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4CC261B948; Tue, 1 Oct 2019 15:19:23 +0200 (CEST) Received: from relay0157.mxlogin.com (relay0157.mxlogin.com [199.181.239.157]) by dpdk.org (Postfix) with ESMTP id 6116D5B3C for ; Tue, 1 Oct 2019 15:19:21 +0200 (CEST) Received: from filter002.mxroute.com (unknown [94.130.183.33]) by relay0157.mxlogin.com (Postfix) with ESMTP id 72008CC4032F; Tue, 1 Oct 2019 08:19:20 -0500 (CDT) Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter002.mxroute.com (Postfix) with ESMTPS id 4597A3F031; Tue, 1 Oct 2019 13:19:14 +0000 (UTC) Received: from [192.198.151.43] by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1iFHuM-0001l0-14; Tue, 01 Oct 2019 09:09:38 -0400 To: Hemant Agrawal , "dev@dpdk.org" Cc: "thomas@monjalon.net" , "stephen@networkplumber.org" , "bruce.richardson@intel.com" , "ferruh.yigit@intel.com" , "konstantin.ananyev@intel.com" , "jerinj@marvell.com" , "olivier.matz@6wind.com" , "nhorman@tuxdriver.com" , "maxime.coquelin@redhat.com" , "john.mcnamara@intel.com" , "marko.kovacevic@intel.com" , "ktraynor@redhat.com" , "aconole@redhat.com" References: <1569603283-1857-1-git-send-email-mdr@ashroe.eu> <1569603283-1857-2-git-send-email-mdr@ashroe.eu> From: Ray Kinsella Openpgp: preference=signencrypt Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: <817c3f46-3216-1051-08a7-19102645e432@ashroe.eu> Date: Tue, 1 Oct 2019 14:19:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH v6 1/4] doc: separate versioning.rst into version and policy X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hemant, Patch 1/4 - doc: separate versioning.rst into version and policy. So it essentially re-organizes the existing policy into two separate documents, one dealing with the policy and the other dealing with the mechanics of abi versioning Patch 2/4 - doc: changes to abi policy introducing major abi versions Actually details the changes to the policy. Other comments inline below. Ray K On 01/10/2019 13:50, Hemant Agrawal wrote: > Hi Ray, > >> +DPDK ABI/API policy >> +=================== >> + >> +Description >> +----------- >> + >> +This document details some methods for handling ABI management in the >> DPDK. >> + >> +General Guidelines >> +------------------ >> + >> +#. Whenever possible, ABI should be preserved #. ABI/API may be changed >> +with a deprecation process #. The modification of symbols can generally >> +be managed with versioning #. Libraries or APIs marked in >> +``experimental`` state may change without constraint #. New APIs will >> +be marked as ``experimental`` for at least one release to allow >> + any issues found by users of the new API to be fixed quickly #. The >> +addition of symbols is generally not problematic #. The removal of >> +symbols generally is an ABI break and requires bumping of the >> + LIBABIVER macro >> +#. Updates to the minimum hardware requirements, which drop support >> for hardware which >> + was previously supported, should be treated as an ABI change. > > [Hemant] You mean the specific HW pmds? > 1. Why dropping HW PMD is a ABI change? So this is part of the original policy and you are correct, it isn't strictly abi - I think the original policy's author, wanted it treated the same way so that a given ABI version would not drop support for hardware. > 2. Even if they are supported across releases, there is no guarantee that they are not broken. True > >> + >> +What is an ABI >> +~~~~~~~~~~~~~~ >> + >> +An ABI (Application Binary Interface) is the set of runtime interfaces >> +exposed by a library. It is similar to an API (Application Programming >> +Interface) but is the result of compilation. It is also effectively >> +cloned when applications link to dynamic libraries. That is to say >> +when an application is compiled to link against dynamic libraries, it >> +is assumed that the ABI remains constant between the time the application >> is compiled/linked, and the time that it runs. >> +Therefore, in the case of dynamic linking, it is critical that an ABI >> +is preserved, or (when modified), done in such a way that the >> +application is unable to behave improperly or in an unexpected fashion. >> + >> + >> +ABI/API Deprecation >> +------------------- >> + >> +The DPDK ABI policy >> +~~~~~~~~~~~~~~~~~~~ >> + >> +ABI versions are set at the time of major release labeling, and the ABI >> +may change multiple times, without warning, between the last release >> +label and the HEAD label of the git tree. >> + >> +ABI versions, once released, are available until such time as their >> +deprecation has been noted in the Release Notes for at least one major >> +release cycle. For example consider the case where the ABI for DPDK 2.0 >> +has been shipped and then a decision is made to modify it during the >> +development of DPDK 2.1. The decision will be recorded in the Release >> +Notes for the DPDK 2.1 release and the modification will be made available >> in the DPDK 2.2 release. >> + > [Hemant] Is it possible to update the DPDK numbering to current versioning, instead of using old 2.x numbering? Already done, see Patch 2/4 >> +ABI versions may be deprecated in whole or in part as needed by a given >> +update. >> + >> +Some ABI changes may be too significant to reasonably maintain multiple >> +versions. In those cases ABI's may be updated without backward >> +compatibility being provided. The requirements for doing so are: >> + >> +#. At least 3 acknowledgments of the need to do so must be made on the >> + dpdk.org mailing list. >> + >> + - The acknowledgment of the maintainer of the component is mandatory, >> or if >> + no maintainer is available for the component, the tree/sub-tree >> maintainer >> + for that component must acknowledge the ABI change instead. >> + >> + - It is also recommended that acknowledgments from different "areas of >> + interest" be sought for each deprecation, for example: from NIC >> vendors, >> + CPU vendors, end-users, etc. >> + >> +#. The changes (including an alternative map file) can be included with >> + deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, >> + to provide more details about oncoming changes. >> + ``RTE_NEXT_ABI`` wrapper will be removed when it become the default >> ABI. > > [Hemant] The older implementation will or can be removed at this point of time? Detailed in Patch 2/4. it says ... At the declaration of the next major ABI version, those ABI changes then become a formal part of the new ABI and the requirement to preserve ABI compatibility with the last major ABI version is then dropped ... Thanks, Ray K