Subject: re: CVS commit: src
To: Christian Limpach <firstname.lastname@example.org>
From: matthew green <email@example.com>
Date: 05/14/2004 01:14:00
From: "matthew green" <firstname.lastname@example.org>
> Log Message:
> ``build.sh -m xen-i386 release'' now builds a release for NetBSD/xen
> for i386. The resulting release consists of:
> - NetBSD/xen for i386 kernel, loader and docuemntation
> - NetBSD/i386 userland sets
> if the userland is the same, is there any particular reason that
> i386 can't just include a "xen" kernel? eg, the way that sparc
> includes a 32bit "sparc64" kernel. see sparc/conf/GENERIC_SUN4U.
I'd actually prefer this since you install NetBSD/i386 first and then switch
to the NetBSD/xen kernel.
There might be 2 problems with this though:
- if arch/i386/conf/GENERIC_XEN doesn't compile, release for i386 will fail
i don't think this is a problem.
- nothing will build the NetBSD/xen loader and documentation
that can be changed... in the sparc* case, both platforms build
the sparc64 loaders (bootblk, which is in forth, and ofwboot,
which is largely in C. the 32 bit ofwboot can load 32 bit or
64 bit kernels.) docs is a SMOD(? :-)
> this would avoid having to have another port to "release".
I was thinking that we could maybe add a knob which prevents building the
sets at all for build.sh -m xen-*.
hmmm something along these lines would be ok if we go this route.