Re: x86 release builds are slow

[Andrew Doran <ad%NetBSD.org@localhost>]

On Thu, May 01, 2008 at 01:36:08PM +0200, Manuel Bouyer wrote:

> On Thu, May 01, 2008 at 02:06:31AM +0100, Andrew Doran wrote:
> > Hi,
> > 
> > For an i386 release build we now build 11 kernels, which takes a long time.
> > To help verification of changes it would be better if release builds didn't
> > take so long.
> > 
> > For i386 and amd64, we could change the process so that the GENERIC kernel
> > is used for installs, and the root file system objcopy'd into a seperate ELF
> > binary that is loaded by the boot loader. We could modify the in-kernel ELF
> > linker to set the root file system image up. Any comments on that?
> > 
> > For xen that might not be possible because GRUB is used. I don't know. If it
> > can't be done, what are the major reasons for having seperate DOM0 and DOMU
> > kernels?
> 
> DOMU kernels don't need any physical device drivers (and because of this,
> DOMU kernels build much faster than dom0 kernels). There's an issue
> with XPMAP_OFFSET being different in some cases.
> It should be possible to have a kernel that can work both dom0 and domU
> for Xen >= 3.1

I will try a few experiments but it will be a while before I have the time.
I'm also interested in the possibility of using multiboot to pass a root
disk image or module to the DOMU kernels for installs.

> but that would make a heavily-bloated domU kernel.
> I'd prefer to keep separate domU kernels, with only the needed code for
> domU operations (A Xen3 dom0 kernel is 9.5MiB, a domU kernel is less
> than 4MiB).

I think that's simply fallacious. Yes, our kernels are too fat and we are
working on that, but you would be hard pushed today to buy a new PC off the
shelf with less than 512MB of RAM. We're speaking of virtualization, not
embedded systems or constrained systems that can just about support one OS.

As of now we build 2 kernels for i386, 2 kernels for amd64, and 11 kernels
for xen. The reasons behind that are technical, it's not a big deal because
we can address the problem easily. However, maintaining all those images in
order to save a few megabytes of memory at runtime is ridiculous. For the
majority of applications it's simply not going to matter, and for corner
cases we provide source code. If someone has a weird application, we have
already provided them the tools they need to make NetBSD a fit.

Andrew