Subject: Kernel sets and non-GENERIC platforms
To: None <tech-install@netbsd.org>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: tech-install
Date: 11/29/2001 10:59:20
Folks...

We currently have a problem when it comes to building snapshots
for platforms which don't really have GENERIC kernels.  The most
obvious ones here are the "eval board" ports.  These ports are
often to system-on-a-chip devices or embedded prototyping boards
for which no "generic" configuration really exists.

There's also some inconsistency regarding how the kernel sets
are named.  GENERIC goes into kern.tgz, but an extra (GENERIC_LAPTOP?)
goes into a set like kern_laptop.tgz.

What I would like to do is this:

	(1) Change all kernel sets to be named kern-CONFIG.tgz,
	    e.g. kern-GENERIC.tgz, kern-IPAQ.tgz, kern-IQ80310.tgz,
	    kern-P5064.tgz, etc.

	(2) Chance each port's etc/${MACHINE}/Makefile.inc to
	    provide a list of kernels to build sets for,
	    rather than assuming GENERIC + ${EXTRA_KERNELS}.
	    We'll call this new variable KERNEL_SETS, as it
	    will directly map to which kernel sets are built.

	(3) Provide some mechanism for optional kernel formats
	    and filename extensions, e.g.:

		netbsd			<- normal ELF kernel
		netbsd.s19		<- S-Records
		netbsd.fxp0		<- normal ELF root-on-fxp0
		netbsd.fxp0.s19		<- S-Records root-on-fxp0

(3) isn't quite as high on my list.  I want to do (1) and (2) first.
Then attack (3).  (3) might include changing the way we plop kernels
in the "binary/kernels" directory of a release package.

I don't have an implementation, yet.  I'm going to start on an
implementation as soon as this email leaves my MUA.  I just want
this discussion to happen in parallel to expedite the process.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>