From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [dpdk-techboard] DPDK ABI/API Stability Date: Thu, 4 Apr 2019 17:37:46 +0100 Message-ID: References: <94df3cc4-de54-72d6-84c6-81bebd209a81@intel.com> <20190404105447.GA1351@bricha3-MOBL.ger.corp.intel.com> <20190404085127.24d02988@shemminger-XPS-13-9360> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Kinsella , dev@dpdk.org, Kevin Traynor , "techboard@dpdk.org" To: Stephen Hemminger , Bruce Richardson Return-path: In-Reply-To: <20190404085127.24d02988@shemminger-XPS-13-9360> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 04-Apr-19 4:51 PM, Stephen Hemminger wrote: > On Thu, 4 Apr 2019 11:54:47 +0100 > Bruce Richardson wrote: > >> My thoughts on the matter are: >> 1. I think we really need to do work to start hiding more of our data >> structures - like what Stephen's latest RFC does. This hiding should reduce >> the scope for ABI breaks. >> 2. Once done, I think we should commit to having an ABI break only in the >> rarest of circumstances, and only with very large justification. I want us >> to get to the point where DPDK releases can immediately be picked up by all >> linux distros and rolled out because they are ABI compatible. > > I would also like to propose "you get one ABI break" which means each > API/ABI change must hide more infrastructure than the last. This is > the "fool me once, ..." saying in API's. > > For example, > the memory rework it would have been good if the structure of mempools etc > were hidden inside EAL and not exposed. but as usual hindsight is 20/20 > Mempools is not part of "memory rework" - it's a separate library built on top of EAL's memory subsystem :) When i talk about "memory API's", i mean memzone/malloc and friends, not mempool. -- Thanks, Anatoly