From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 3DF577F40 for ; Thu, 20 Nov 2014 17:59:02 +0100 (CET) Received: by mail-wg0-f43.google.com with SMTP id l18so4356683wgh.2 for ; Thu, 20 Nov 2014 09:09:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=4bsUTyK6CZafxpbxmtP2HMOcTnDn8TtKPyF0jnsIRns=; b=SleHUIGuk9O1Rsojw152EB1RYA/GeAg+snJblOoJ6jJr5/v0sljnv0kSRVUfe57Epx uDSj8VslmUTaJ2x1t7o2Vz6BOcBk8ZeO9Qj0+EZot9sao4CD8+FjF/caFL46ltiZ7Jeo 3iogzL2ZULXO3nTdAjPee4xebPlK39eY2ALW9bVSO+SvvUczrK/E4vBSYW3DRdmD7rHv /VgUBJat11pFgk2t8+o0lFziZHc6ndTKKSTY1Cavy94Nm4/sH/eG6WwqqXyEG1M1ts9d 3L1sVzOh5rbR+Itax5fNAID6uhJyP7b4l49bApL+X509YSZg1EF1OI1GpgFXk42sISQx a0kQ== X-Gm-Message-State: ALoCoQlqwSO3Hdf+AcPbGE74gboYLu128ZmqMlvB3iPQgv8oGiyrRcaIYrJJu1sebbXP18QR7CPd X-Received: by 10.180.211.108 with SMTP id nb12mr6163696wic.76.1416503372952; Thu, 20 Nov 2014 09:09:32 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id h14sm3472354wic.8.2014.11.20.09.09.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Nov 2014 09:09:32 -0800 (PST) From: Thomas Monjalon To: Neil Horman Date: Thu, 20 Nov 2014 18:09:10 +0100 Message-ID: <1824872.LRtPTHvm1g@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.2-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: <20141119151343.GC28013@localhost.localdomain> References: <5606183.AkpK27L7yz@xps13> <20141119113507.GA2604@bricha3-MOBL3> <20141119151343.GC28013@localhost.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] versioning and maintenance 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, 20 Nov 2014 16:59:02 -0000 Hi, 2014-11-19 10:13, Neil Horman: > On Wed, Nov 19, 2014 at 11:35:08AM +0000, Bruce Richardson wrote: > > On Wed, Nov 19, 2014 at 12:22:14PM +0100, Thomas Monjalon wrote: > > > Following the discussion we had with Neil during the conference call, > > > I suggest this plan, starting with the next release (2.0): > > > - add version numbers to libraries > > > - add version numbers to functions inside .map files > > > - create a git tree dedicated to maintenance and API compatibility > > > > > > It means these version numbers must be incremented when breaking the API. > > > Though the old code paths will be maintained and tested separately by volunteers. > > > A mailing list for maintenance purpose could be created if needed. > > > > > Hi Thomas, > > > > I really think that the versionning is best handled inside the main repository > > itself. Given that the proposed deprecation policy is over two releases i.e. an > > API is marked deprecated in release X and then removed in X+1, I don't see the > > maintaining of old code paths to be particularly onerous. > > > > /Bruce > > I agree with Bruce, even if it is on occasion an added workload, its not the > sort of thing that can or should be placed on an alternate developer. Backwards > compatibility is the sort of thing that has to be on the mind of the developer > when modifying an API, and on the mind of the reviewer when reviewing code. To > shunt that responsibility elsewhere invites the opportunity for backwards > compatibilty to be a second class citizen who's goal will never be reached, > because developers instituting ABI changes will never care about the > consequences, and anyone worrying about backwards compatibility will always be > playing catch up, possibly allowing ABI breaks to slip through. > > Neil Before taking a decision, we should detail every concern. 1/ Currently there are not a lot of API refactoring because DPDK is well tailored for x86 and Intel NICs. But we are seeing that new CPU and new NICs to support would require some adaptations. 2/ I'm curious to know how you would handle a big change like the recent mbuf rework. Should we duplicate the structure and all the functions using mbuf? 3/ Should we add new fields at the end of its structure to avoid ABI breaking? 4/ Developers contribute because they need some changes. So when breaking an API, their application is already ready for the new version. I mean the author of such patch is probably not really motivated to keep ABI compability and duplicate the code path. 5/ Intead of simply modifying an API function, it would appear as a whole new function with some differences compared to the old one. Such change is really not convenient to review. 6/ Testing ABI compatibility could be tricky. We would need a tool to check it's mostly OK. The good place for such a tool is in app/test. It was designed to be the unit tests of the API. 7/ This system would allow application developpers to upgrade DPDK to n+1 without rebuilding. But when upgrading to n+2, they should have adapted their application to comply with n+1 API (because n will be removed). So this solution offers a delay between the upgrade decision and the app work. Note that they could prepare their application before upgrading. Anyway, an upgrade should be tested before doing it effectively. The behaviour of the application could change and require some adaptations. 8/ How to handle a change in the implementation of a PMD which severely impact the application? Example: an ol_flag was mis-used and the application has a workaround to interpret this flag but it's now incompatible with the fix. 9/ When we don't want to adapt an application, it means the development is finished and we don't care about the new features of the library. So I wonder if it wouldn't be more appropriate to provide stable releases with true maintenance to such users. I understood that is what Redhat provides to their customers. Hope this discussion will bring a clear idea of what should be done with which implications. Thanks -- Thomas