Date: Fri, 16 Jan 2015 11:01:46 -0700 From: Warner Losh <imp@bsdimp.com> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Warner Losh <imp@FreeBSD.org>, Slawa Olhovchenkov <slw@zxy.spb.ru> Subject: Re: svn commit: r277204 - head/sys/amd64/conf Message-ID: <8CA7406B-9962-4DED-A509-14851128F43B@bsdimp.com> In-Reply-To: <20150115134446.GA92636@FreeBSD.org> References: <201501150042.t0F0g7Um018059@svn.freebsd.org> <20150115132303.GA245@zxy.spb.ru> <20150115134446.GA92636@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Jan 15, 2015, at 6:44 AM, Alexey Dokuchaev <danfe@FreeBSD.org> wrote: > > 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. Too many things, sadly, are kernel options and the functionality is absent when or reduced when loading from a module. > 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). (2) is the exact problem I’m working on. Since the design of that will allow us to read from the kernel these modules, (1) becomes largely irrelevant because the only /boot/loader incursion would be to load drivers for any storage devices that are on the PCIe bus. > 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. Perhaps. Let’s see how my stuff plays out, since it generally would mean we could use a more minimal kernel and let the system figure out what other things should be loaded. Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUuVIKAAoJEGwc0Sh9sBEAPqAP/1ksobiazMXPCCCff1kwqEdp EPBJh94ERMu+hJD+3zBE+2Zlc02KGlto5zt6d5fTvzWTx4w+DOzbIPjMznOQhrZ/ xx2CK3wabE+dH+wy0+wiszDh9rjQNgPAct9Yw65zAHLEWt5Z2TTGoevSxJVrMDiQ LQoVElZeuhnxLp/RBlI8292c6KLat73RgJqrqaQ+ZqpZiJjzbvlwUjqa51wu7t4w oOo2M+/cGqYdcx+16CF0GNMNasHRFJpk4un1gCiZVafRz3YuVSlcciBkMbJJnvJC G6imEmte3X+b5eR6VmcCLJSGVKxQQeDeP+6yk6W6cvpN5c+e2IVnoYl7Dq5rlQCW NPLRpGaxeu6sIdyPcwIXkFIrn0vUYof04FA/JC3kypcBLvWNuezzywqGewhOhaUs PFbh3P+TpwEWCnm2ulhmZhxTa7z3JP2QZnwGA5wvIGUxOPbb0mfC5QZ+kwFBnYUT BsvMdk/jKTFPAOEs/eu6IGJ2xlvWB07Kk/2in/nNm/f3b3rsLYHN7ei8/apfVZl4 f2eI18yHep1mqWjFB3mHZ0xLuf15S6RPh2n04aZtdnb5Eu/gC0pLSljXsE37/ytM ie82jpGfST5c3MdV1ycHakqNf5skvOmMwC+ND1uMSOs4Lolo0madt1tOT+cTs53b 1x+ZurfCYefJWFrP53WW =aYih -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CA7406B-9962-4DED-A509-14851128F43B>