Re: [Ksummit-discuss] Should we force include <linux/err.h> when compiling all .c files?

[Josh Triplett <josh@joshtriplett.org>]

On Fri, Jul 25, 2014 at 01:39:39PM +0100, David Howells wrote:
> Should we forcibly include <linux/err.h> from the gcc command line when
> compiling all .c files?  Note:
> 
> 	warthog>git grep -l '#.*include.*<linux/err[.]h>' -- \*.c | wc -l
> 	1797
> 
> vs:
> 
> 	warthog>git grep -l 'IS_ERR\|ERR_PTR\|PTR_ERR\|ERR_CAST' -- \*.c | wc -l
> 	4472
> 
> So a lot fewer .c files include it than use it, but according to:
> 
> 	1: If you use a facility then #include the file that defines/declares
> 	   that facility.  Don't depend on other header files pulling in ones
> 	   that you use.
> 
> as pointed out to me by Stephen, it shouldn't be assumed that it's available.
> 
> 
> However, passing errors in pointers is so very common within the kernel, it
> might worth be adding linux/err.h to the automatically included stuff.

~/src/linux$ git grep -l 'IS_ERR\|ERR_PTR\|PTR_ERR\|ERR_CAST' -- '*.c' | wc -l
4467
~/src/linux$ find -name '*.c' | wc -l
20430

Functionality used by less than a quarter of the source files in the
kernel doesn't make sense to automatically include.  You have a clear
test that shows whether a file uses this functionality, which would
allow an automated patch adding the necessary #include lines.

That does raise an interesting general issue, though: when a change to
the kernel would involve patching several thousand files, and would
potentially produce a huge number of conflicts (and a huge number of
patches if broken out by subsystem) if fed through the normal process,
but can be described by a very short script that requires no manual
intervention, might it make sense to have a clear procedure for saying
"Hey Linus, can you please run this script on top-of-tree and commit the
result?"?

- Josh Triplett