Project

General

Profile

Actions

Feature #202

open

Some kconfig_lint warnings don't get posted to Gerrit

Added by Julius Werner over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
infrastructure
Target version:
-
Start date:
04/05/2019
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:

Description

https://review.coreboot.org/c/coreboot/+/31776 added some new kconfig_lint warnings related to the CONFIG() macro. The intention was that these would get posted as comments to Gerrit to alert developers, but that somehow doesn't seem to happen (e.g. here https://review.coreboot.org/c/coreboot/+/29917/30/src/cpu/amd/family_10h-family_15h/init_cpus.c#1061). If I run the linter locally I can see the warning show up with the right file and line number. I assume this is a bug with the code that parses linter output and generates Gerrit comments out of them? I don't know where that lives, it doesn't seem to be in the tree.

Actions #1

Updated by Patrick Georgi over 5 years ago

  • Tracker changed from Bug to Feature

Right now the jenkins job that returns warnings only runs (and therefore returns) the checkpatch script. I guess we'll have to extend it to run kconfig_lint, too?

Actions #2

Updated by Julius Werner over 5 years ago

Right now the jenkins job that returns warnings only runs (and therefore returns) the checkpatch script. I guess we'll have to extend it to run kconfig_lint, too?

Oh, really? I could've sworn I had seen this before, that's the whole reason I added those warnings there. Maybe I confused it with the actual kconfig_lint errors that block Verified+1.

I think adding it would be neat, especially for warnings like "unused symbol", "unknown config option" or "naked reference to CONFIG_xxx" (where there are so many in the tree right now that it wouldn't be easy to clean them up, but new additions are still very likely to be mistakes). But alternatively we can also turn a few more into full errors (at least "CONFIG() used on unknown value", since that seems to be a common mistake and cleaning up false positives wasn't too disruptive).

Actions

Also available in: Atom PDF