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