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 at 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
