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 15452A051C; Fri, 17 Jan 2020 20:02:16 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 407B54C8B; Fri, 17 Jan 2020 20:02:15 +0100 (CET) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id B4A7649DF for ; Fri, 17 Jan 2020 20:02:10 +0100 (CET) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1isWsR-0000hx-Sl; Fri, 17 Jan 2020 14:02:02 -0500 Date: Fri, 17 Jan 2020 14:01:45 -0500 From: Neil Horman To: Thomas Monjalon Cc: David Marchand , "Richardson, Bruce" , "dev@dpdk.org" , "Laatz, Kevin" , "aconole@redhat.com" , Michael Santana , "Mcnamara, John" , "Kovacevic, Marko" , "Kinsella, Ray" Message-ID: <20200117190145.GA8752@hmswarspite.think-freely.org> References: <20191220152058.10739-1-david.marchand@redhat.com> <3426618.TKLx3GfHUD@xps> <20200116184928.GA8633@hmswarspite.think-freely.org> <2375800.otXNkdZ6W1@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2375800.otXNkdZ6W1@xps> X-Spam-Score: -2.9 (--) X-Spam-Status: No 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" On Thu, Jan 16, 2020 at 09:01:52PM +0100, Thomas Monjalon wrote: > 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. > Hmmm....I wonder if its worth orchestrating the build system to use a git submodule storing whatever our CI system can produce and using it as a cache, and falling back to a local build if the appropriate arch isn't found? That might offer some incentive to alternate arch maintainers to contribute hardware or compute time to populating it in pursuit of better build times? Neil > >