Re: [dpdk-dev] [PATCH v6 00/11] Add ABI compatibility checks to the meson build

[Aaron Conole <aconole@redhat.com>]

Bruce Richardson <bruce.richardson@intel.com> 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
>> <bruce.richardson@intel.com> 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 some
>> > > 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 maintainer
>> > should not have his own copy, I think.
>> 
>> 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.
>> 
>
> I don't think it will be quite that big, but ok, it may be significant, so
> I will concede that these are too big to store in the main git repo.
>
>> 
>> 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?
>> 
>
> 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 with
> 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?

>> 
>> > > * 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?
>> 
>> Creating a separate git repo is just adding more pain to submitters
>> (/maintainers): they would have to submit (/apply) patches against two
>> trees.
>> 
>
> 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 people
> with different versions of the ABI to check against. Everyone should check
> 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