Date: Mon, 31 Oct 2005 12:42:46 -0500 From: John Baldwin <jhb@freebsd.org> To: obrien@freebsd.org Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf DEFAULTS GENERIC Message-ID: <200510311242.47729.jhb@freebsd.org> In-Reply-To: <20051030062148.GA76667@dragon.NUXI.org> References: <200510271734.j9RHYZAk015054@repoman.freebsd.org> <20051030062148.GA76667@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 30 October 2005 01:21 am, David O'Brien wrote: > On Thu, Oct 27, 2005 at 05:34:35PM +0000, John Baldwin wrote: > > jhb 2005-10-27 17:34:35 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/conf GENERIC > > Added files: > > sys/i386/conf DEFAULTS > > Log: > > Create a default kernel config for i386 and move 'device isa' and > > 'device npx' (both of which aren't really optional right now) and > > 'device io' and 'device mem' (to preserve POLA for 4.x users upgrading > > to 6.0) from GENERIC into DEFAULTS. > > I may be missing something. I don't quite follow the benefit of the new > 'DEFAULTS' file. I'm also curious why we don't explicitly 'include' > DEFAULTS in GENERIC vs. the new automagic include feature. We can now make more things optional without breaking POLA for existing users. Imagine if atpic became optional on i386. Folks who didn't update their i386 kernel configs would all break. With DEFAULTS, I can make it optional without breaking anyone's kernel configs, and the 3 people that want it off can use 'nodevice atpic'. > I wonder if someone might trip over this not realizing everything that > winds up in their config file. I for one have been using io.ko and > mem.ko after coping GENERIC to FOO and removing the 'io' and 'mem' > devices. It was considered for the io/mem case that the set of people doing what you are doing is far smaller than the set of people moving directly from 4.x to 6.x who might miss adding the new options and end up with headaches. I don't think very much at all should be in DEFAULTS, just stuff that really should be enabled for nearly everyone and that one should explicitly go and turn off. To answer other questions: no, INCLUDE_CONFIG_FILE will not handle DEFAULTS at all. Consider DEFAULTS as part of the system config like sys/conf/files. The other alternative thrown around was to use things like 'dev/mem/mem.c default mem' to make that file default to on and you had to use 'nodevice mem' to turn it off. That is a system setting much like the fact that we include mutexes in the kernel by default. :) We don't dump the list of all the files that were marked 'standard' when we do INCLUDE_CONFIG_FILE. DEFAULTS is a less error-prone way of achieving things that are on by default than 'dev/mem/mem.c default mem' since the latter can result in interesting edge cases where what if one file from a module is default and the other optional? DEFAULTS lets you turn things on at the device/option granularity rather than file-level granularity. To my mind, things that should be in DEFAULTS are things that only a few people might want to trim out for space reasons (nanobsd), etc. For example, when I backported acpi to 4.x, I didn't maek pmtimer optional, I made it standard instead. To be honest, I can't think of any reason other than paranoid space savings to have pmtimer optional, and I think that is another possible candidate for DEFAULTS. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510311242.47729.jhb>