Proposal: TEST kernel config files

[Jeff Rizzo <riz%netbsd.org@localhost>]

The problem as I see it:  it would be useful to have extra kernel 
options available by default when performing automated testing* on 
various platforms, but in most cases none of the available kernel 
configurations have the desired options** enabled (on the assumption 
that a developer who desires these options can build a custom 
configuration with relatively little bother).  In some of the 
automated-testing cases, it would be convenient and arguably beneficial 
to be able to use the already-existing autobuilds*** for testing 
purposes.  Since the kernels aren't available by default, to achieve the 
goal of testing with non-default options, it would be necessary to 
configure the test platform with a custom kernel configuration file.

Given the push for automated testing that we're currently making (very 
successfully, I might add), it seems to me that having these 
configurations _available by default_ makes it easier to maintain a 
uniform testing strategy.  However, various people have rightly pointed 
out that it's quite a burden to make everyone building NetBSD build 
extra kernels they don't use unless they customize their own builds.

What I propose is a compromise:  let's create a kernel configuration 
file for each arch which is intended for testing, but NOT have it be 
part of the default build.  If the file is there already, and named 
consistently, it's a simple matter to make sure it's built when needed 
as part of the standard release build mechanism.  The releng autobuild 
cluster could be configured to build the kernel for those platforms with 
regular testing occurring, and make it available in the snapshots;  but 
not built for releases.

For most platforms (this is obviously up to the portmaster and whomever 
is running the primary test rig), the TEST**** kernel would be something 
like this:

include "arch/macppc/conf/GENERIC"
options DIAGNOSTIC
options LOCKDEBUG

...where GENERIC can be any kernel suitable for a starting point, and 
the options are ones generally decided upon.  Anyone doing continuous 
build-and-test would build this kernel and use it for at least some 
testing; anyone testing against the autobuilds would be able to request 
the kernel be built as part of the autobuilds.  Any arch where it makes 
sense would have a config file added.

Thoughts?

Thanks for reading this far,
+j


* See http://releng.netbsd.org/test-results.html
** DIAGNOSTIC, LOCKDEBUG, - others?
*** http://releng.netbsd.org/cgi-bin/builds.cgi
**** The name is up for bikeshedding.  The name TEST is not in currently 
in use by any platform under -current.