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 45902A04F1; Mon, 6 Jan 2020 14:21:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8FC061C010; Mon, 6 Jan 2020 14:20:59 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 764EE1D65D for ; Mon, 6 Jan 2020 14:20:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578316857; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TDUVUUqrKcNUNn6iqYncekwENhh1eCD2jheaXKDXh60=; b=cQEufs46Y9MPrMLn2iVAz8jULVHlvGO1pgiFokb2t8jD+RuY+VpeVBM1ezhVBIQ+hr4PYG rXzMNBMhiM/V/SzhgRaYJ9sHGSoSIEZHqsglIGU02OPZwTA0K3iXA91Z4XOf5GYs2NjVVk HT3za6N4mX39qGIjEh3Di/PNpmgysNw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-407-VTbDHOg-Oui0drdpEbRUJQ-1; Mon, 06 Jan 2020 08:20:56 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EA522100551A; Mon, 6 Jan 2020 13:20:54 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.108]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8AC3B1A7E3; Mon, 6 Jan 2020 13:20:51 +0000 (UTC) From: Aaron Conole To: Bruce Richardson Cc: David Marchand , Kevin Laatz , dev , Thomas Monjalon , "Kinsella\, Ray" , Tomasz Duszynski , Zyta Szpak , Rastislav Cernay References: <20191213140302.4252-1-kevin.laatz@intel.com> <20191213164110.9744-1-kevin.laatz@intel.com> <20191220110414.GA514@bricha3-MOBL.ger.corp.intel.com> <20191220141723.GA526@bricha3-MOBL.ger.corp.intel.com> Date: Mon, 06 Jan 2020 08:20:50 -0500 In-Reply-To: <20191220141723.GA526@bricha3-MOBL.ger.corp.intel.com> (Bruce Richardson's message of "Fri, 20 Dec 2019 14:17:23 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: VTbDHOg-Oui0drdpEbRUJQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v6 00/11] Add ABI compatibility checks to the meson build 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" Bruce Richardson writes: > On Fri, Dec 20, 2019 at 02:19:13PM +0100, David Marchand wrote: >> On Fri, Dec 20, 2019 at 12:04 PM Bruce Richardson >> wrote: >> > > For maintainers that integrate patches or developers that get a CI >> > > failure and want to fix it, we would need to help them to: >> > > * generate dumps on a reference version, so I would tend to write so= me >> > > documentation since playing with the current sources would be too >> > > dangerous from my pov, >> > >> > This should be a one-off reference dump archived somewhere. Each maint= ainer >> > should not have his own copy, I think. >>=20 >> This is not a one-off thing. >> We maintain ABI for some time (1/2 year(s)), and we expect to bump ABI. >> When doing this, in size, the diff will be at least the same than what >> we have here. >>=20 > > I don't think it will be quite that big, but ok, it may be significant, s= o > I will concede that these are too big to store in the main git repo. > >>=20 >> If you disable libraries, features etc... you get a new ABI. >> What would be the reference*s* then? >> Builds with default options from meson for each architecture? >>=20 > > On the project level API, yes, removing libraries/drivers does affect > things. However, the specific checks are done on the individual .so level= , > so having some drivers off in the build should not be a problem. Even wit= h > features - all public functions need to correspond with map file entries, > so we can't conditionally remove them without providing a stub AFAIK. > Therefore, having one master reference of the DPDK_20 ABI is perfectly > feasible. But when is it cut? What happens during an interrim, where users have an outdated reference but don't remember what they downloaded? What about when we have multiple LTS' that have different ABI versions and need to ensure that we don't break ABIs for backports? >>=20 >> > > * run the checks, like adding the check in the >> > > devtools/test-*-build.sh scripts that already exist, with a new >> > > configuration item to point at the dumps per target, >> > > >> > >> > Where do we store the dumps then? Do they get stored in a separate git >> > repo? >>=20 >> Creating a separate git repo is just adding more pain to submitters >> (/maintainers): they would have to submit (/apply) patches against two >> trees. >>=20 > > Well, the official ABI dumps need to be stored somewhere, because if it's > an official ABI, then it is exactly that. There cannot be different peopl= e > with different versions of the ABI to check against. Everyone should chec= k > against the one common, official reference. Isn't the reference stored in the git repo anyway? It should always be possible to generate it. And I trust the version I generate from the source of truth anyway, over something I download. > Regards, > /Bruce