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

[Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>]

On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
> Alright, how's this new description:
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index cac3f096050d..73e4890c24c4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -53,6 +53,34 @@ config CROSS_COMPILE
>         need to set this unless you want the configured kernel build
>         directory to select the cross-compiler automatically.
>  
> +config BUILD_AVOID_BITROT
> +     bool "Always force building specially annotated targets"
> +     default n
> +     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. Enabling this option helps avoid code bit
> +       rot by taking advantage of the facilities provided and enabled by
> +       using linker tables documented under:

As a kernel developer I have _no_ idea what this is trying to say at
all, sorry.

What is a "specially annotated target"?  Who is forcing it to be built?
What does it mean if it isn't built?

> +
> +       include/linux/tables.h
> +
> +       The special targets supported are:
> +
> +         o table-obj-y
> +         o table-lib-y

What does this mean to me as a developer?  What does it mean to a user
who wants to figure out if it should be enabled or not?

> +
> +       Say Y if you have a decent build machine and would like to help test
> +       building code for more subsystems. Say N if you do you not have a
> +       good build machine or only want to compile what you've enabled for
> +       your kernel.

How does this test different subsystems?  How does disabling it not test
them?  Why would I care either way?

> +
> +       Enabling this option never increases the size of your kernel.

Then what does it do?  Just burn electricity for no reason?

totally confused...

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel