Date: Mon, 02 Oct 2017 10:46:06 -0600 From: Ian Lepore <ian@freebsd.org> To: Russell Haley <russ.haley@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) Message-ID: <1506962766.22078.69.camel@freebsd.org> In-Reply-To: <CABx9NuS9XAfWNHM1fAFKV8byhWyv=jXS_W%2BNO3Y6s-CtEQdp6A@mail.gmail.com> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <CABx9NuS9XAfWNHM1fAFKV8byhWyv=jXS_W%2BNO3Y6s-CtEQdp6A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2017-10-02 at 09:11 -0700, Russell Haley wrote:
> [...]
>=20
> 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'?
>=20
> Russ
>=20
I keep asking (on irc mostly) and not getting any answer to:
Why are we working towards a GENERIC kernel for arm? =A0Who benefits?
=A0What 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. =A0Nobody 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).
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. =A0You 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. =A0If only someone would mention some.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1506962766.22078.69.camel>