GENERIC kernel (was Re: BeagleBone Crochet Build Problem)

Mark Millard markmi at dsl-only.net
Mon Oct 2 17:11:08 UTC 2017


[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



More information about the freebsd-arm mailing list