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>