From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 6A52C5918 for ; Wed, 8 Oct 2014 20:38:51 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 08 Oct 2014 11:36:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="397235257" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by FMSMGA003.fm.intel.com with ESMTP; 08 Oct 2014 11:39:17 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.253]) by IRSMSX101.ger.corp.intel.com ([169.254.1.201]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 19:46:05 +0100 From: "Butler, Siobhan A" To: Thomas Monjalon , Neil Horman Thread-Topic: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility Thread-Index: AQHP4xCpNLjo92XaBkmFwgTdaDyOnpwmh/DA Date: Wed, 8 Oct 2014 18:46:05 +0000 Message-ID: <0C5AFCA4B3408848ADF2A3073F7D8CC86D444BB1@IRSMSX109.ger.corp.intel.com> References: <1410809031-19114-1-git-send-email-nhorman@tuxdriver.com> <20141001185940.GA27437@hmsreliant.think-freely.org> <20141007210135.GH27719@hmsreliant.think-freely.org> <4923174.cbZvBc6Zut@xps13> In-Reply-To: <4923174.cbZvBc6Zut@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility 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: Wed, 08 Oct 2014 18:38:52 -0000 From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon Sent: Wednesday, October 8, 2014 4:57 PM To: Neil Horman Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support ba= ckwards 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, > > > >=20 > > > > 2014-09-24 14:19, Neil Horman: > > > > > Ping Thomas. I know you're busy, but I would like this to not=20 > > > > > fall off anyones radar. You alluded to concerns regarding=20 > > > > > what, for lack of a better term, ABI/API lockin. I had asked=20 > > > > > you to enuumerate/elaborate on specifics, but never heard=20 > > > > > back. Are there further specifics you wish to discuss, or are yo= u satisfied with the above answers? > > > >=20 > > > > Sorry for not being very reactive on this thread. > > > > All this discussion is very interesting but it's really not the=20 > > > > proper time to apply it. As you said, it requires an extra=20 > > > > effort. I'm not saying it will never be integrated. I'm just=20 > > > > saying that we cannot change everything at the same time. > > > >=20 > > > > Let me sum up the situation. This community project has been=20 > > > > very active for few months now. First, we learnt how to make=20 > > > > some releases together and we are improving the process to be=20 > > > > able to deliver a new major release every 4 months while having som= e good quality process. > > > > But these releases are still not complete because documentation=20 > > > > is not integrated yet. Then developers should have a role in docume= ntation updates. > > > > We also need to integrate and learn how to use more tools to be=20 > > > > more efficient and improve quality. > > > >=20 > > > > 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=20 > > > > pace which allow most of us to stay in the race. > > >=20 > > > I'm sorry Thomas, I don't accept this. I asked you for details as=20 > > > to your concerns regarding this patch series, and you've provided mor= e vague comments. > > > I need details to address > > >=20 > > > You say it requires extra effort, you're right it does. Any=20 > > > feature that you integreate requires some additional effort. How=20 > > > is this patch any different from adding the acl library or any=20 > > > other new API? Everything requires maintenence, thats how=20 > > > software works. What specfically about this patch series makes the e= ffort insurmountable to you? > > >=20 > > > You say you're improving your process. Great, this patch aids in=20 > > > that process by ensuring backwards compatibility for a period of=20 > > > time. Given that the API and ABI can still evolve within this=20 > > > framework, as I've described, how is this patch series not a signific= ant step forward toward your goal of quality process. > > >=20 > > > You say documentation isn't integrated. So, what does getting=20 > > > documentation integrated have to do with this patch set, or any=20 > > > other? I don't see you holding any other patches based on=20 > > > documentation. Again, nothing in this series prevents evolution=20 > > > of the API or ABI. If you're hope is to wait until everything is=20 > > > 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. > > >=20 > > > You say you also need to learn to use more tools to be more=20 > > > efficient and improve quality. Great! Thats exactly what this=20 > > > is. If we mandate even a short term commitment to ABI stability (1=20 > > > single relese worth of time), we will quickly identify what API's=20 > > > change quickly and where we need to be cautious with our API=20 > > > design. If you just assume that developers will get better of their = own volition, it will never happen. > > >=20 > > > You say this should go in next year, but not now. When exactly? =20 > > > What event do you forsee occuring in the next 12-18 months that=20 > > > will change everything such that we can start supporing an ABI for=20 > > > more than just a few weeks at the head of the tree? > > >=20 > > > To this end, I just did a quick search through the git history for=20 > > > dpdk to look at the histories of all the header files that are=20 > > > exposed via the makefile SYMLINK command (given that that provides=20 > > > a list of header files that applications can include, and embodies=20 > > > all the function symbols and data types applications have access to. > > >=20 > > > There are 179 total commits in that list Of those, a bit of spot=20 > > > checking suggests that about 10-15% of them actually change ABI,=20 > > > 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=20 > > > update would have been needed. That seems pretty reasonable to=20 > > > me. Where exactly is your concern here? > >=20 > > Ping Thomas, I'd like to continue this debate to a conclusion. =20 > > Could you please provide specific details and/or concerns that you have= with this patch series? > >=20 > Ping again Thomas, please lets debate this to a reasonable consensus. =20 > 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 co= nfident >>>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 change= s are really important. We need a conclusion as you both mentioned. I see T= homas' 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 som= e 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 f= urther out? Siobhan=20