Re: [dpdk-dev] [PATCH v4 1/4] ethdev: rename rte_eth_vmdq_mirror_conf

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jul 08, 2015 at 10:31:15AM +0000, Mcnamara, John wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, July 7, 2015 3:51 PM
> > To: Wu, Jingjing
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: rename
> > rte_eth_vmdq_mirror_conf
> > 
> > > Additional, about the validate-abi.sh, does it mean we need to fix all
> > > the problems it reports? Or we can decide case by case.
> > > Can a Low Severity problem be acceptable?
> > 
> > We have to decide case by case.
> > It makes ABI checking impossible to automate.
> > That's why any help is welcome to check the git HEAD for ABI violation.
> 
> Hi,
> 
> Automated testing for ABI breaks is tricky since it requires some interpretation of the errors and the severity level.
> 
> However, each report file contains a 2 line summary at the top that can be read and parsed. For example (with long lines wrapped):
> 
>     head -2 compat_reports/librte_mbuf.so/v2.0.0_to_ABI_CHECK/compat_report.html
> 
>     <!-- kind:binary;verdict:compatible;affected:0;added:1;removed:0;
>          type_problems_high:0;type_problems_medium:0;type_problems_low:0;
>          interface_problems_high:0;interface_problems_medium:0;
>          interface_problems_low:0;changed_constants:0;tool_version:1.99.8.5 -->
>     <!-- kind:source;verdict:compatible;affected:0;added:1;removed:0;
>          type_problems_high:0;type_problems_medium:0;type_problems_low:0;
>          interface_problems_high:0;interface_problems_medium:0;
>          interface_problems_low:0;changed_constants:0;tool_version:1.99.8.5 -->
> 
> This still requires interpretation but it can be used to search for categories of incompatibility.
> 
> To test if a patchset breaks the API it is possible to do something like the following. Say, for example that you have committed 3 commits to your local master, you could tag and run the checker like this:
> 
>     git checkout master
> 
>     git tag -f ABI_CHECK_AFTER
>     git tag -f ABI_CHECK_BEFORE HEAD~3
> 
>     ./scripts/validate-abi.sh ABI_CHECK_BEFORE ABI_CHECK_AFTER x86_64-native-linuxapp-gcc
> 
>     grep -lr "kind:binary;verdict:incompatible" compat_reports/
> 
> The grep could be extended to match other categories that you are interested in. However, it is still probably better to examine the reports manually.
> 
> You can also use something this to run a git bisect to find a commit that introduced an ABI incompatibility:
> 
>     # Tag the head and some known good point in the history.
>     git checkout master
>     git tag -f ABI_CHECK_END
>     git tag -f ABI_CHECK_START v2.0.0
> 
>     # Start git bisect with bad and good.
>     git bisect start ABI_CHECK_END ABI_CHECK_START
> 
>     # Run bisect with a script.
>     git bisect run ~/abi_bisect.sh
> 
> Where the ~/abi_bisect.sh script that searches for ABI incompatibilities looks like this:
> 
>     #!/bin/sh
> 
>     git tag -f ABI_CHECK_END
> 
>     rm -rf compat_reports/
> 
>     ./scripts/validate-abi.sh ABI_CHECK_START ABI_CHECK_END x86_64-native-linuxapp-gcc
> 
>     ! grep -lr "kind:binary;verdict:incompatible" compat_reports/
> 
> John.
> -- 

I'd mod this post up as "+1 informative", except that this isn't slashdot. :-)

Very helpful, John. Thanks.

/Bruce