Date: Wed, 21 Feb 2018 11:58:49 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Ian Lepore <ian@freebsd.org> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: Custom kernel for RPi2 and 3 Message-ID: <201802211958.w1LJwnhu087548@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <1519242042.91697.116.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Charset ISO-8859-1 unsupported, converting... ] > 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. I think we have diverged a long way from what was originally a GENERIC kernel. It was not meant to be the dumping ground containing all and every feature, it was suppose to be a kernel that could boot on as many systems as you could so that you could get up and running to build a custom kernel. That concept has pretty much faded away, imho, this is unfortanant. I do not think your alone in your thinking, especially for ARM or embeded type systems. Last time I tried to support the issue of people should really be building a custom kernel and not running GENERIC I pretty much got shot down as "this is 2018 no one should have to build a kernel". > > 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. I make a copy of GENERIC, delete 90% of it as I dont need it, save this in CUSTOM. I diff GENERIC CUSTOM and carry that forward with me on upgrades to take out what i had taken out before, and also diff GENERIC.last to GENERIC to see what got added. The nooptions is probably a more effective way to do this. > > 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. A few things I dislike about this all module singing situation is we have lost some of the documentation on if you want to statically link in stuff, or it is much harder to find now. Netgraph comes to mind. And god forbid people think I am crazy for static linking in zfs, but I like it that way, I never have to worry about module mismatch if I am futzing about. > -- Ian -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201802211958.w1LJwnhu087548>