GENERIC kernel (was Re: BeagleBone Crochet Build Problem)

[Russell Haley]

On Mon, Oct 2, 2017 at 10:10 AM, Mark Millard <markmi at dsl-only.net> wrote:
> [I'm not arguing against the points or questions:
> just noting a specific technique for CPU-targeting
> the built kernel code.]
>
> On 2017-Oct-2, at 9:46 AM, Ian Lepore <ian at freebsd.org> wrote:
>
>> On Mon, 2017-10-02 at 09:11 -0700, Russell Haley wrote:
>>> [...]
>>>
>>> Looks like someone is moving some of the kernel config files over to
>>> GENERIC. Is using GENERIC on arm something that is being encouraged by
>>> those 'in the know'?
>>>
>>> Russ
>>>
>>
>> I keep asking (on irc mostly) and not getting any answer to:
>>
>>    Why are we working towards a GENERIC kernel for arm?  Who benefits?
>>     What do they get that they don't have now?
>>
>> There seems to be this general impression that a generic kernel is a
>> good thing, or even somehow a required thing.  Nobody explains why.
>>
>> I know some anti-answers to the above questions.
>>
>>    A GENERIC arm kernel does not reduce the number of different arm
>>    images we have to distribute; that still comes out to roughly one-
>>    per-board or system or related family of systems, because they still
>>    need hardware-specific u-boot.
>>
>>    A GENERIC kernel gives worse performance than a per-soc kernel for
>>    virtually every soc since we have to compile for the lowest common
>>    denominator (things like using software divide on systems that have
>>    hardware divide instructions).
>
> I use src.conf files for CPU targeting, for both native and cross
> building. For example (cross build):
>
> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.amd64-host
> TO_TYPE=aarch64
> TOOLS_TO_TYPE=${TO_TYPE}
> #
> KERNCONF=GENERIC-NODBG
> TARGET=arm64
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITH_CROSS_COMPILER=
> WITHOUT_SYSTEM_COMPILER=
> #
> WITH_LIBCPLUSPLUS=
> WITHOUT_BINUTILS_BOOTSTRAP=
> WITH_ELFTOOLCHAIN_BOOTSTRAP=
> WITH_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLD_BOOTSTRAP=
> WITH_LLD=
> WITH_LLD_IS_LD=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> #
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_REPRODUCIBLE_BUILD=
> WITH_DEBUG_FILES=
> #
> XCFLAGS+= -mcpu=cortex-a53
> XCXXFLAGS+= -mcpu=cortex-a53
> # There is no XCPPFLAGS but XCPP gets XCFLAGS content.
>
>
> And for native I used the C<?>FLAGS.clang notation:
>
> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host
> TO_TYPE=aarch64
> TOOLS_TO_TYPE=${TO_TYPE}
> #
> KERNCONF=GENERIC-NODBG
> TARGET=arm64
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> #WITH_CROSS_COMPILER=
> WITH_SYSTEM_COMPILER=
> #
> #CPUTYPE=soft
> WITH_LIBCPLUSPLUS=
> WITHOUT_BINUTILS_BOOTSTRAP=
> WITH_ELFTOOLCHAIN_BOOTSTRAP=
> #WITHOUT_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLD_BOOTSTRAP=
> WITH_LLD=
> WITH_LLD_IS_LD=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> #
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_REPRODUCIBLE_BUILD=
> WITH_DEBUG_FILES=
> #
> # Use of the .clang 's here avoids
> # interfering with other C<?>FLAGS
> # usage, such as ?= usage.
> CFLAGS.clang+= -mcpu=cortex-a53
> CXXFLAGS.clang+= -mcpu=cortex-a53
> CPPFLAGS.clang+= -mcpu=cortex-a53
>
>
>>    The x86-world advice of creating your custom kernel config by doing
>>    "include GENERIC" then adding "nodevice" and "nooption" statements
>>    to turn off what you don't want is a non-starter with an arm GENERIC
>>    kernel.  You would need sooo many lines of nodevice to turn off soc-
>>    specific stuff for other socs, and also since new socs and drivers
>>    are always being added, you'd be endlessly chasing a moving target.
>>
>>    Given the above problem with "include GENERIC", and without a per-
>>    soc kernel config to start with, there is no practical way to create
>>    a future-proof custom kernel config.
>>
>> I'm not, at this point, claiming that these downsides are a reason to
>> avoid working towards GENERIC, but since there are clearly some
>> downsides, it seems like a situation where you want to weigh those
>> against the benefits.  If only someone would mention some.
>
>
> ===
> Mark Millard
> markmi at dsl-only.net

What advantage do does this confer to your testing?

Russ