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

[Josh Triplett <josh@joshtriplett.org>]

On Mon, Jul 28, 2014 at 11:52:28AM -0700, H. Peter Anvin wrote:
> 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*.

That sounds sensible.  Is that documented anywhere?

- Josh Triplett