I see no issues with this (and always was bothered by the obvious non
symetry when EXTRA_KERNELS got added)

James

>
>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>
>
>
>
>