[dpdk-dev] [PATCH v4 1/4] ethdev: rename rte_eth_vmdq_mirror_conf
Bruce Richardson
bruce.richardson at intel.com
Wed Jul 8 12:35:16 CEST 2015
On Wed, Jul 08, 2015 at 10:31:15AM +0000, Mcnamara, John wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, July 7, 2015 3:51 PM
> > To: Wu, Jingjing
> > Cc: dev at 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
More information about the dev
mailing list