From owner-freebsd-arm@freebsd.org Mon Oct 2 16:51:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AF42E0E70A for ; Mon, 2 Oct 2017 16:51:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1855C6EE7D for ; Mon, 2 Oct 2017 16:51:54 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 24EAB5C2289 for ; Mon, 2 Oct 2017 16:46:14 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.127.23]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 951295C2454 for ; Mon, 2 Oct 2017 16:46:13 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.55.158]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Mon, 02 Oct 2017 16:46:14 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Grain-Descriptive: 00546921365556a0_1506962773995_3664556356 X-MC-Loop-Signature: 1506962773995:3199701644 X-MC-Ingress-Time: 1506962773995 X-MHO-User: 30d54b90-a791-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 30d54b90-a791-11e7-a893-25625093991c; Mon, 02 Oct 2017 16:46:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v92Gk6WX003772; Mon, 2 Oct 2017 10:46:06 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506962766.22078.69.camel@freebsd.org> Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) From: Ian Lepore To: Russell Haley Cc: freebsd-arm Date: Mon, 02 Oct 2017 10:46:06 -0600 In-Reply-To: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:51:55 -0000 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