From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9DA7168BD for ; Thu, 10 Apr 2014 12:53:06 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1WYCcv-00014p-HJ; Thu, 10 Apr 2014 06:54:42 -0400 Date: Thu, 10 Apr 2014 06:54:36 -0400 From: Neil Horman To: Stephen Hemminger Message-ID: <20140410105436.GB10459@hmsreliant.think-freely.org> References: <20140409183952.GA16493@hmsreliant.think-freely.org> <20140409140849.176db9be@nehalam.linuxnetplumber.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140409140849.176db9be@nehalam.linuxnetplumber.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] DPDK API/ABI Stability 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: Thu, 10 Apr 2014 10:53:06 -0000 On Wed, Apr 09, 2014 at 02:08:49PM -0700, Stephen Hemminger wrote: > On Wed, 9 Apr 2014 14:39:52 -0400 > Neil Horman wrote: > > > Hey all- > > I was going to include this as an addendum to the packaging thread on > > this list, but I can't seem to find it in my inbox, so forgive me starting a new > > one. > > > > I wanted to broach the subject of ABI/API stability on the list here. > > Given the recent great efforts to make dpdk packagable by disributions, I think > > we probably need to discuss API stability in more depth and come up with a plan > > to implement it. Has anyone started looking into this? If not, it seems to me > > to be reasonable to start by placing a line in the sand with the functions > > documented here: > > > > http://dpdk.org/doc/api/ > > > > It seems to me we can start reviewing the API library by library, enusring only > > those functions are exported, making sure the data types are appropriate for > > export, and marking them with a linker script to version them appropriately. > > To what level? source? binary, internal functions? > Well, I was thinking both (hence the API/ABI comment above), but at least API stability as a start. Stabilizing internal functions doesn't make any sense to me since, by definition those aren't exposed to users trying to make use of the library. > Some of the API's could be stablized without much impact but others such > as the device driver interface is incomplete and freezing it would make > live hard. But the driver interface isn't listed on the api documentation above. Clearly we'd need to address that eventually, but as a start it can likely be ignored, at least we can give applications a modicum of stability. Neil