From owner-freebsd-arm@freebsd.org Wed Feb 21 19:40:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F15DF23A22 for ; Wed, 21 Feb 2018 19:40:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 0B9C36E44B for ; Wed, 21 Feb 2018 19:40:44 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 076df97d-173f-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 076df97d-173f-11e8-b951-f99fef315fd9; Wed, 21 Feb 2018 19:40:11 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1LJegYN061421; Wed, 21 Feb 2018 12:40:42 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1519242042.91697.116.camel@freebsd.org> Subject: Re: Custom kernel for RPi2 and 3 From: Ian Lepore To: bob prohaska Cc: George Rosamond , freebsd-arm@freebsd.org Date: Wed, 21 Feb 2018 12:40:42 -0700 In-Reply-To: <20180221181518.GA696@www.zefox.net> References: <20180220161900.GA2345@www.zefox.net> <20180221051801.GA73510@www.zefox.net> <1519229812.91697.61.camel@freebsd.org> <20180221181518.GA696@www.zefox.net> 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: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:40:45 -0000 On Wed, 2018-02-21 at 10:15 -0800, bob prohaska wrote: > On Wed, Feb 21, 2018 at 09:16:52AM -0700, Ian Lepore wrote: > > > > On Wed, 2018-02-21 at 05:44 +0000, George Rosamond wrote: > > > > > > bob prohaska: > > > > > > > > > > > > [...] > > > Bob: > > > > > > This script can generate an /etc/src.conf based on the running system, > > > extracted from /etc/src.conf(5). Since there's no standard /etc/src.conf > > > through FreeBSD versions, it's a hassle to maintain without it. > > > > > > http://wiki.torbsd.org/doku.php?id=en:a_shell_script_to_convert_src.conf_5_contents_to_an_example_etc_src.conf_file > > > > > > HTH > > That script looks like a really complicated way to do: > > > > ? make showconfig __MAKE_CONF=/dev/null SRCCONF=/dev/null > > > > -- Ian > Is there a straightforward way to sort what's being used from what > can't (or isn't) being used? For example, on a Pi2 the command emits > MK_WIRELESS      = yes > MK_WIRELESS_SUPPORT = yes > Given that there's no onboard wireless and no USB WiFi adapter, it's > fairly obvious those two can be set to "no". It's less clear what  > MK_TEXTPROC      = yes > portends, and whether it's essential. > > Perhaps I mis-posed the original question. What I'm looking for might > better be called a minimal kernel configuration supporting only the > hardware native to a particular board. The old RPI2 kernel config file > seemed to do that, but I gather it's deprecated.  > > Thanks for reading! > > bob prohaska >   Well, for starters all the WITH/WITHOUT stuff affects only userland, not kernel builds.  So setting WITHOUT_WIRELESS will leave the 'wpa' program out of the build/installworld, but has no effect on whether any wireless stuff is compiled in the kernel or modules. When it comes to GENERIC kernels and how to slim them down... I should start by mentioning that I've hated GENERIC kernels going back to 1996 or so, but at least they made some kind of sense for x86 machines that all had so much in common with each other.  For ARM I think the concept is somewhere between useless and actively harmful.  I seem to be pretty much alone in thinking so.  If we ever get to the point where a generic kernel can contain almost nothing in the way of options and drivers, and the right modules can be dynamically loaded during boot as needed, that would be useful. So about the only way to make a custom slim kernel these days if your platform is based on GENERIC is create a custom config file, include GENERIC, then write a series of nooption and nodevice statements that turn off all the stuff you don't want.  That ensures that if new required stuff gets added in the future, you'll pick it up.  It also ensures that when new stuff you don't need gets added, you'll also get burdened with all of that.  Given that an arm generic kernel contains all the stuff needed by every arm SoC, it's a pretty good bet that almost everything added to generic in the future will be things you don't need, and on every update you'll have to examine it looking for what got added that you now need new nooption/nodevice statements for. There's no good way to figure out what you need and what you don't other than to read GENERIC line by line, hoping that the comments (when they exist at all) give you enough of a clue about whether you need that line.  Sometimes you need to look in sys/arm/conf/NOTES and in sys/conf/NOTES to find the info on what a given device or option is. -- Ian