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

["H. Peter Anvin" <hpa@zytor.com>]

On 07/25/2014 04:24 PM, Josh Triplett wrote:
>>
>> 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?"?
> 

We have such a clear procedure.  It involves pre-arranging with Linus
*before the merge window begins* to run the script in question
*immediately before releasing rc1*.

	-hpa