From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 22BAC3792 for ; Mon, 6 Jul 2015 15:51:00 +0200 (CEST) Received: by wgqq4 with SMTP id q4so141114204wgq.1 for ; Mon, 06 Jul 2015 06:51:00 -0700 (PDT) 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=A46gawLUk8739+2Yq8qT+12ZOsDQAKWYo4C/8WTsrR4=; b=PtuXC4PkkFqpbF+j3jHMWj3TYY/O+2BGm0rT0GO/e+SZIz/FZbcCbFV6ZOxnbRAFT4 cfAGBv1ahugeGgcz9MWeQhPWnmNZasulg27ndTU5Qd22iGYkXS6lQ6EzIGY11yvs1vL/ gHRIUz9nIVnijOw5weI+prKjroa5LfVZsP1osN2PhCcB6+zRUfYK7OynK0dN+/I33eeD LSWX2m7mZtCWPp2LmEY111w5Omvk9kaiWNbiNdNuq6n7Cxna4eDr+0ZA1n8FKamCUBlw DKu6PiyURAYd2X1lO+OT+a3AfX748TaNl8ERBwMyWAlYlUVvRFak8OyGFevy6xRrzqYL i83w== X-Gm-Message-State: ALoCoQnWYJZZKV/sXFKS73TWFRo9vpxeq/dRT0MmBklbW7j2QEt9jM+YOjHLsdAYjM9AU71yegP5 X-Received: by 10.180.84.170 with SMTP id a10mr54573644wiz.52.1436190659935; Mon, 06 Jul 2015 06:50:59 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id u7sm47361153wif.3.2015.07.06.06.50.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 06:50:59 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Mon, 06 Jul 2015 15:49:50 +0200 Message-ID: <3961609.5kzAKlCGhe@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150706133544.GA30816@hmsreliant.think-freely.org> References: <1435874746-32095-1-git-send-email-thomas.monjalon@6wind.com> <10048439.cxXN29b43P@xps13> <20150706133544.GA30816@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: enable next abi in static libs 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: Mon, 06 Jul 2015 13:51:00 -0000 2015-07-06 09:35, Neil Horman: > On Mon, Jul 06, 2015 at 03:18:51PM +0200, Thomas Monjalon wrote: > > Any comment or ack? > > > > 2015-07-03 00:05, Thomas Monjalon: > > > When a change makes really hard to keep ABI compatibility, > > > instead of waiting next release to break the ABI, it is smoother > > > to introduce the new code and enable it only for static libraries. > > > The flag RTE_NEXT_ABI may be used to "ifdef" the new code. > > > When the release is out, a dynamically linked application can use > > > the new shared libraries without rebuild while developpers can prepare > > > their application for the next ABI by reading the deprecation notice > > > and easily testing the new code. > > > When starting the next release cycle, the "ifdefs" will be removed > > > and the ABI break will be marked by incrementing LIBABIVER. > > > > > > The new option CONFIG_RTE_NEXT_ABI is not defined in the configuration > > > templates because it is deduced from CONFIG_RTE_BUILD_SHARED_LIB. > > > It is automatically enabled for static libraries and disabled for > > > shared libraries. > > > It can be forced to another value by editing the generated .config file. > > > It shouldn't be enabled for shared libraries because it would break the > > > ABI without changing the version number LIBABIVER. That's why a warning > > > is printed in this case. > > > > > > The guideline is also updated to integrate this new possibility. > > > > > > Signed-off-by: Thomas Monjalon > > > > > Yeah, I'm not sure why this is necessecary. That is to say, if you want to It's explained at the beginning: "When a change makes really hard to keep ABI compatibility", e.g. mbuf change. > introduce a new ABI operation prior to the old one being removed, that is precisely what > the versioning macros are for, and can be used to map the static api to the new > version. e.g, given function X that you want to enhance in an ABI breaking way: > > 1) Separate function X to X_v1 and X_v2 > 2) Map X_v2 to X@DPDK_v2, map X_v1 to X@DPDK_v1 > 3) Map the static symbol X to X_v2 > 4) Post the deprecation notice of X for release 3 immediately We cannot do that for mbuf change. > Splitting the static ABI from the shared ABI just means that applications will > have the opportunity to isolate themselves to one kind of build, which is a bad > idea. It helps to be prepared for the next release by testing the app with static libraries. We agreed to allow API breaking for important changes like mbuf rework. This option NEXT_ABI is a step between announcement and effective ABI breaking. I think it's a reasonnable approach. But if nobody ack it, I'm perfectly OK to drop it and related features (unified packet type and interrupt mode).