Date: Mon, 2 Oct 2017 11:46:26 -0700 From: Russell Haley <russ.haley@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) Message-ID: <CABx9NuTkJfCvx-i8LYqBmk7A-%2BpJi03HmyPPooMARW=zvfkrcQ@mail.gmail.com> In-Reply-To: <6B133241-6C83-4FE4-B5E8-D3302B3579B4@dsl-only.net> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <CABx9NuS9XAfWNHM1fAFKV8byhWyv=jXS_W%2BNO3Y6s-CtEQdp6A@mail.gmail.com> <1506962766.22078.69.camel@freebsd.org> <6B133241-6C83-4FE4-B5E8-D3302B3579B4@dsl-only.net>
index | next in thread | previous in thread | raw e-mail
On Mon, Oct 2, 2017 at 10:10 AM, Mark Millard <markmi@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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuTkJfCvx-i8LYqBmk7A-%2BpJi03HmyPPooMARW=zvfkrcQ>