Date: Thu, 15 Jan 2015 13:44:46 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Warner Losh <imp@FreeBSD.org> Subject: Re: svn commit: r277204 - head/sys/amd64/conf Message-ID: <20150115134446.GA92636@FreeBSD.org> In-Reply-To: <20150115132303.GA245@zxy.spb.ru> References: <201501150042.t0F0g7Um018059@svn.freebsd.org> <20150115132303.GA245@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 15, 2015 at 04:23:03PM +0300, Slawa Olhovchenkov wrote: > On Thu, Jan 15, 2015 at 12:42:07AM +0000, Warner Losh wrote: > > New Revision: 277204 > > URL: https://svnweb.freebsd.org/changeset/base/277204 > > > > Log: > > New MINIMAL kernel config. The goal with this configuration is to > > only compile in those options in GENERIC that cannot be loaded as > > modules. ufs is still included because many of its options aren't > > present in the kernel module. There's some other exceptions documented > > Are you sure? > I think defining UFS options in kernel connfig affect to module too. > When I define this options in kernel config (w/o options FFS) I got > ufs.ko with this SU, quota, acl etc. > > [...] > This is loadable too. Right, it does not look like minimal to me either. But I welcome the intention. AFAIR last time we had a discussion about why our default kernel is not MINIMAL, it boiled down to two main problems: 1) loader's caching of disk reads (which makes loading *.ko's from /boot/loader.conf a PITA, esp. on ZFS), and 2) robust way to figure out which modules to load on an arbitrary user's system (so they won't have to write their /boot/loader.conf from scratch themselves). Speaking of (1), I recall there was one or two attempts to address it (keyword: fast-loader-3.diff). Can someone with more details on their hands comment a bit what had happened to that work and are there any ETA for it to get committed? That would be a big leap forward towards minimal kernel which can be feasible enough to replace (or be a real alternative to) GENERIC in the future. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150115134446.GA92636>