[dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility

Butler, Siobhan A siobhan.a.butler at intel.com
Wed Oct 8 20:46:05 CEST 2014


From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
Sent: Wednesday, October 8, 2014 4:57 PM
To: Neil Horman
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility

Hi Neil,

2014-10-07 17:01, Neil Horman:
> On Wed, Oct 01, 2014 at 02:59:40PM -0400, Neil Horman wrote:
> > On Fri, Sep 26, 2014 at 10:45:49AM -0400, Neil Horman wrote:
> > > On Fri, Sep 26, 2014 at 12:41:33PM +0200, Thomas Monjalon wrote:
> > > > Hi Neil,
> > > > 
> > > > 2014-09-24 14:19, Neil Horman:
> > > > > Ping Thomas. I know you're busy, but I would like this to not 
> > > > > fall off anyones radar.  You alluded to concerns regarding 
> > > > > what, for lack of a better term, ABI/API lockin.  I had asked 
> > > > > you to enuumerate/elaborate on specifics, but never heard 
> > > > > back.  Are there further specifics you wish to discuss, or are you satisfied with the above answers?
> > > > 
> > > > Sorry for not being very reactive on this thread.
> > > > All this discussion is very interesting but it's really not the 
> > > > proper time to apply it. As you said, it requires an extra 
> > > > effort. I'm not saying it will never be integrated. I'm just 
> > > > saying that we cannot change everything at the same time.
> > > > 
> > > > Let me sum up the situation. This community project has been 
> > > > very active for few months now. First, we learnt how to make 
> > > > some releases together and we are improving the process to be 
> > > > able to deliver a new major release every 4 months while having some good quality process.
> > > > But these releases are still not complete because documentation 
> > > > is not integrated yet. Then developers should have a role in documentation updates.
> > > > We also need to integrate and learn how to use more tools to be 
> > > > more efficient and improve quality.
> > > > 
> > > > So the question is "when should we care about API compatibility"?
> > > > And the answer is: ASAP, but not now. I feel next year is a better target.
> > > > Because the most important priority is to move together at a 
> > > > pace which allow most of us to stay in the race.
> > > 
> > > I'm sorry Thomas, I don't accept this.  I asked you for details as 
> > > to your concerns regarding this patch series, and you've provided more vague comments.
> > > I need details to address
> > > 
> > > You say it requires extra effort, you're right it does.  Any 
> > > feature that you integreate requires some additional effort.  How 
> > > is this patch any different from adding the acl library or any 
> > > other new API?  Everything requires maintenence, thats how 
> > > software works.  What specfically about this patch series makes the effort insurmountable to you?
> > > 
> > > You say you're improving your process.  Great, this patch aids in 
> > > that process by ensuring backwards compatibility for a period of 
> > > time.  Given that the API and ABI can still evolve within this 
> > > framework, as I've described, how is this patch series not a significant step forward toward your goal of quality process.
> > > 
> > > You say documentation isn't integrated.  So, what does getting 
> > > documentation integrated have to do with this patch set, or any 
> > > other?  I don't see you holding any other patches based on 
> > > documentation.  Again, nothing in this series prevents evolution 
> > > of the API or ABI.  If you're hope is to wait until everything is 
> > > perfect, then apply some control to the public facing API, and get it all documented, none of thosse things will ever happen, I promise you.
> > > 
> > > You say you also need to learn to use more tools to be more 
> > > efficient and improve quality.  Great!  Thats exactly what this 
> > > is. If we mandate even a short term commitment to ABI stability (1 
> > > single relese worth of time), we will quickly identify what API's 
> > > change quickly and where we need to be cautious with our API 
> > > design.  If you just assume that developers will get better of their own volition, it will never happen.
> > > 
> > > You say this should go in next year, but not now.  When exactly?  
> > > What event do you forsee occuring in the next 12-18 months that 
> > > will change everything such that we can start supporing an ABI for 
> > > more than just a few weeks at the head of the tree?
> > > 
> > > To this end, I just did a quick search through the git history for 
> > > dpdk to look at the histories of all the header files that are 
> > > exposed via the makefile SYMLINK command (given that that provides 
> > > a list of header files that applications can include, and embodies 
> > > all the function symbols and data types applications have access to.
> > > 
> > > There are 179 total commits in that list Of those, a bit of spot 
> > > checking suggests that about 10-15% of them actually change ABI, 
> > > and many of those came from Bruce's rework of the mbuf structure.
> > > That about 17-20 instances over the last 2 years where an ABI 
> > > update would have been needed.  That seems pretty reasonable to 
> > > me.  Where exactly is your concern here?
> > 
> > Ping Thomas, I'd like to continue this debate to a conclusion.  
> > Could you please provide specific details and/or concerns that you have with this patch series?
> > 
> Ping again Thomas, please lets debate this to a reasonable consensus.  
> Ignoring it won't help anything.

>>>I'm not ignoring the discussion, I was trying to focus on other topics.

>>>You're right, we need a conclusion.
>>>This patch is an important change which needs time to be finely checked and tested. So I plan to integrate it in version 2.0 which will be the next one >>>after 1.8 release. In the mean time you could test this patch with Fedora and see how it helps application packaging. Then we could be more confident >>>that we are applying the right policy starting with 2.0.

>>>Thanks Neil, I appreciate your involvement in DPDK
>>>--
>>>Thomas

Neil, Thomas,

I think Neil is correct here - these API/ABI compatibility/stability changes are really important. We need a conclusion as you both mentioned. I see Thomas' points about caution and needing time, but it seems like there is no point in prolonging the inevitable and having consider all of this for some time I think it might be wise to just adjust and get on with it? If these changes cannot be ready in the near term, what will make them more ready further out?

Siobhan 


More information about the dev mailing list