> We can run it without actually building htmldocs. The only requirement
> is to have Python 3.6 or above (this is enough to get error reports,
> but 3.7 is needed to avoid having struct/function parameters out of
> order).
>
> The real problem is that, when we start doing it, Kernel build will
> have thousands of warnings.
>
> Perhaps one solution would be to have an image of our current
> problems on a file, reporting only new stuff by default and using
> WERROR policy, causing build to fail on new warnings.
>
> This would at least avoid the problem to increase.
netdev has a CI system which is used to try to evaluate every patch
for problems. It builds the HEAD of net-next, and counts the number of
compiler warnings, for the whole tree. If then applies the patches in
a patch series, one by one, and runs the build for each patch, and
counts the number of compiler Warnings. If the number of warnings goes
up, the test fails.
Does the kernel docs have any concept of incremental builds? Adding
one patch and rebuilding the kernel is generally fast, unless it
changes an important header. So the cost is reasonably small for two
builds. But if building the kernel documentation twice is going to
cost 6 minutes, this does not scale.
What the netdev CI also does is collect the names of the files a patch
will change. It runs ./scripts/kernel-doc -Wall -none $FILES, without
the patch, to get the number of warnings, applies the patch and does
./scripts/kernel-doc again and checks the number of warnings has not
gone up. That catches a number of undocumented new structure members
etc.
Could something similar be added to 0-day?
Andrew
