Re: [dpdk-dev] DPDK API/ABI Stability

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Apr 09, 2014 at 02:08:49PM -0700, Stephen Hemminger wrote:
> On Wed, 9 Apr 2014 14:39:52 -0400
> Neil Horman <nhorman@tuxdriver.com> 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