Subject: Re: CVS commit: src
To: matthew green <firstname.lastname@example.org>
From: Christian Limpach <email@example.com>
Date: 05/13/2004 18:15:34
On Fri, May 14, 2004 at 01:14:00AM +1000, matthew green wrote:
> 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.
It has the definite advantage that anybody making changes to arch/i386
which break the xen kernel build will notice sooner.
> - 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(? :-)
The loader build could be added to src/etc/etc.i386/Makefile.inc's
snap_md_post target and src/sys/arch/Makefile would probably have
to enter arch/xen when building for i386. Alternatively the loader
could be moved under arch/i386/stand since it's i386 specific
I'm struggling with the docs anyway since the structure of INSTALL.*
doesn't really fit.
> > 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.
I have a slight preference for "release with i386".