Re: [RFC v3 07/13] tables.h: add linker table support

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Fri, Aug 12, 2016 at 09:25:07AM +0200, Borislav Petkov wrote:
> On Fri, Aug 12, 2016 at 08:50:11AM +0200, Luis R. Rodriguez wrote:
> > On Fri, Aug 12, 2016 at 07:23:03AM +0200, Borislav Petkov wrote:
> > > On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote:
> > > > OK I've added CONFIG_BUILD_AVOID_BITROT.
> > > 
> > > What does that do?
> > 
> > 
> > Enabling it allows the forced compilation chosen by maintainers.
> > Otherwise forced compilations with the new special targets are
> > ignored.
> 
> Nice.
> 
> > I've gone with table-obj-y and table-lib-y as we have
> > to support both lib-y and obj-y respective targets.
> > 
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 33e2966dd741..7893e3b8da82 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -1895,6 +1895,30 @@ config PROVIDE_OHCI1394_DMA_INIT
> >  
> >  	  See Documentation/debugging-via-ohci1394.txt for more information.
> >  
> > +config BUILD_AVOID_BITROT
> > +	bool "Always force building specially annotated"
> 
> 					   ...annotated targets"
> 
> > +	default y
> > +	help
> > +	  If enabled then the the special table-* Makefile targets will always
> > +	  be forced to be compiled even if their respective CONFIG_ option has
> > +	  been disabled, but its objects will only be linked in if the same
> > +	  respective CONFIG_ option has been enabled. This helps avoid code
> > +	  bit rot issues, use for these targets should be carefully considred
> > +	  by maintainers. You can safely enable this option at the expense of
> > +	  increasing compile time slightly. Enabling this option helps avoid
> 
> s/slightly//
> 
> :-)
> 
> > +	  code bit rot by taking advantage of the facilities provided and
> > +	  enabled by using linker tables documented under:
> > +
> > +	  include/linux/tables.h
> > +
> > +	  The special targets supported are:
> > +
> > +	    o table-obj-y
> > +	    o table-lib-y
> > +
> > +	  Say Y unless you are a grumpy maintainer and don't trust other
> > +	  maintainer's judgements on what code should always get compiled.
> 
> ... or you're running a tiny-config setup

Even so, you don't link the compiled extra code so the only penalty
here is when compiling, nothing more. And if you are compiling typically
the cost here is just a few seconds.

> ... or you're an embedded, resource-constrained person

For the compilation of th kernel ?

> ... or you simply don't want to have stuff which is forcibly enabled on you even
> if you're never going to need it
> ...

Which seems to be the same as the reason I noted ?

> I got a million o'those :-)

I can remove the grumpy maintainer description :)

 Luis