From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 00025A051A; Thu, 16 Jan 2020 21:02:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EF8221D52A; Thu, 16 Jan 2020 21:01:59 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id F09791D451 for ; Thu, 16 Jan 2020 21:01:57 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7ABC321B8B; Thu, 16 Jan 2020 15:01:56 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 16 Jan 2020 15:01:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=1+dUdAPamHCFABo+He+nuylxeTiBiADhsUsJK8mucPM=; b=N/4KLuqwyaFA p3bOKduZ/0mQ9JQLZU6gyhyMwPsrRVBrNWgOUNT9cr0ncjh9vUq2XFmf2Xai73eV cJ+OsJbjgno4H+enPWTct7aHaZc8RqsC0LfGflhoAKT7+C+OnhiUwKljyBFviVKU t8AbrR2ExqXFUibHuHSkZF2DdNG7dI0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=1+dUdAPamHCFABo+He+nuylxeTiBiADhsUsJK8muc PM=; b=PYjvhvuYqLBU0pgbj4Aiu0w/N3iEjESl5Lsr+zGBSVTx0vcRPAlKDNuAU qt6/CU6YhsQ4nc2rVcS/R3qRwqQ3XZa5diAXl3sv3Eah31kZ9mAf3nZvGWdFUNIv q5kiA4yQxp4ZnGF5I0DcsgcIQILUJ4asHJ2CWkE6pD3zgaYuG82132R4OToWd8Mk 7xCVt5MF3akpzIARul8JR1j/ZwBL3Kiz2Zr8cGdaq3j9KDfCanGjY3Yqqawxb8sN cWThuCjZAJ9FPrAqYVw4AWSZfMt2iTE3vMBR0+Mmfqe/QTvEmoOmyWAhvKluuyqK lexBpGEt4Yx6inVpEOPgOSLlkuVjA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdehgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 060743060840; Thu, 16 Jan 2020 15:01:54 -0500 (EST) From: Thomas Monjalon To: Neil Horman Cc: David Marchand , "Richardson, Bruce" , "dev@dpdk.org" , "Laatz, Kevin" , "aconole@redhat.com" , Michael Santana , "Mcnamara, John" , "Kovacevic, Marko" , "Kinsella, Ray" Date: Thu, 16 Jan 2020 21:01:52 +0100 Message-ID: <2375800.otXNkdZ6W1@xps> In-Reply-To: <20200116184928.GA8633@hmswarspite.think-freely.org> References: <20191220152058.10739-1-david.marchand@redhat.com> <3426618.TKLx3GfHUD@xps> <20200116184928.GA8633@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] add ABI checks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 16/01/2020 19:49, Neil Horman: > On Thu, Jan 16, 2020 at 03:20:48PM +0100, Thomas Monjalon wrote: > > 16/01/2020 12:52, Neil Horman: > > > On Wed, Jan 15, 2020 at 01:38:17PM +0100, Thomas Monjalon wrote: > > > > 15/01/2020 12:33, Neil Horman: > > > > > On Wed, Jan 15, 2020 at 12:19:30AM +0100, Thomas Monjalon wrote: > > > > > > 20/12/2019 17:20, Kinsella, Ray: > > > > > > > From: Richardson, Bruce > > > > > > > > From: David Marchand > > > > > > > > > +Checking ABI compatibility > > > > > > > > > +-------------------------- > > > > > > > > > + > > > > > > > > > +The first thing is to build reference binaries for the latest > > > > > > > > release > > > > > > > > > +your patches are built on top of. > > > > > > > > > + > > > > > > > > > +Either you are in a git tree and an easy way to identify this is to > > > > > > > > run:: > > > > > > > > > + > > > > > > > > > + git checkout $(git describe --abbrev=0) > > > > > > > > > + > > > > > > > > > +Or you use a tarball and you extract the sources in a director of > > > > > > > > > +your > > > > > > > > > choice. > > > > > > > > > + > > > > > > > > > +Next is building those sources, refer to the previous paragraph. > > > > > > > > > +You can set ``DPDK_BUILD_TEST_DIR=reference``, so that the builds > > > > > > > > > +occur in this directory. > > > > > > > > > + > > > > > > > > > +Finally, the ABI dump files are generated with the > > > > > > > > > +``devtools/gen-abi-reference.sh`` script. This script will look for > > > > > > > > > +builds in the current sub directory ``reference``. But you can set > > > > > > > > > +the environment variable ``DPDK_ABI_REF_BUILD_DIR`` to a different > > > > > > > > location. > > > > > > > > > + > > > > > > > > > +Once done, you can check your current binaries ABI with this > > > > > > > > > +reference with the ``devtools/check-abi-reference.sh`` script. > > > > > > > > > > > > > > > > > > > > > > > > > I still very much dislike forcing the user to generate his own > > > > > > > > reference version to compare the ABI against. These should be archived > > > > > > > > and the user should just be able to pull them down via git or http or > > > > > > > > otherwise. Two reasons for this: > > > > > > > > > > > > > > > > 1. Less error prone, since there is no chance of the user having an > > > > > > > > incorrect build for whatever reason. > > > > > > > > > > > > > > > > 2. Less effort for the user than asking them to do extra builds. The > > > > > > > > more steps the user has to follow, the less likely they are to attempt > > > > > > > > the process. > > > > > > > > > > > > > > +1 ... 100% agree with this. > > > > > > > > > > > > > > Many people won't know or understand what the reference is, > > > > > > > or why they to generate it. > > > > > > > > > > > > I don't want to generate and save the reference in git for each arch. > > > > > > > > > > > Can I ask what your reluctance is? Is it related to not wanting to have to save > > > > > all this information that is otherwise not used for building purposes? > > > > > > > > Yes I prefer keeping only the sources in the repository. > > > > And these dumps are big. > > > > And last but not the least, there is no ready-to-use environment to build > > > > and dump all libs for all archs. > > > > > > > > > If so I might suggest saving the dumps in a separate git tree and pulling them > > > > > in as a git submodule when the check is performed > > > > > > > > > > I really like the idea of caching the results so everyone is working from a > > > > > known ABI baseline. > > > > > > > > You don't trust the result of the build made from tagged sources? > > > > > > > I trust the result from the tools, sure, its trusting that people will take the > > > extra time to build a version from a prior tag that I'm less sure of. > > > Consistent use in my mind is predicated on ease and timeliness of use. > > > > > > I get not wanting to store large dumps in the source tree, but storage is cheap, > > > and I don't see the issue with storing the xml dump in a separate git tree to be > > > referenced through a git submodule that gets pulled in when the check is run. > > > > Yes this is an option. > > My fear is that this reference database will not be complete > > if we don't build it for all libraries/drivers on all archs, > > managing setups and dependencies. > > > I can understand that, but I would have assumed that we would have done all > config build for all supported arches as part of the CI for a release, from > which we could archive the results. Is that not the case? No, we don't have a fully complete setup covering all dependencies and archs.