[dpdk-dev] Coverity policy for upstream (base) drivers.

Mcnamara, John john.mcnamara at intel.com
Fri Nov 13 01:12:04 CET 2015


> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Thursday, November 12, 2015 10:05 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: [dpdk-dev] Coverity policy for upstream (base) drivers.
> 
> Looking at the Coverity scan for DPDK, it looks like all the base drivers
> are marked to be ignored.
> 
> Although the changes to base drivers should not be done directly through
> DPDK list. I think it is still valuable to have these driver scanned and
> notify (badger) the vendors to fix there code.
> 
> Since lots of the bugs could be there, just blindly ignoring warnings and
> issues is being naive.

Hi Stephen,

I set up the Coverity rules. I added the ignore rules for the base drivers on the assumption that the DPDK community wasn't, in most cases, going to be able to fix issues that occurred in them. However, as you say, it is best to know about potential bugs even if there isn't a direct route to fix them.

If we are going to turn on analysis of the base drivers then maybe we can wait until after we have a baseline for DPDK 2.3 since I presume there will be a flood of issues and I don't want the new issues in this release (that we can fix more readily) to get lost.

The base drivers aside, we have 114 open issues that should be fixed, or marked as investigated and safe to ignore. Also, the analysis is currently run with only the default DPDK config options. I'll extend the analysis to run as many of the non-default config items as possible.

If people haven't already done so I would urge them to sign up and view/fix the defects.

    https://scan.coverity.com/users/sign_up
    https://scan.coverity.com/projects/4005 (DPDK)

Apply as "Contributor/Member" if you plan to review/close issues or as "Defect Viewer" if you just wish to see the issues.

I've recently set up a script to identify the likely author of new Coverity defects based on git blame, and to email them the defect report. It isn't 100% accurate, in particular for whitespace changes around existing defects, but it is a start.

John.
-- 










More information about the dev mailing list