ATF-devel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: About testing "self-buildability"



Jukka Ruohonen wrote:
> First: the motivation for this is the bug partially described in kern/45361.
> A new PR will follow, as it seems that NetBSD 6.0 BETA can not reliably
> build itself in all settings (i.e. building the sources panics the system).
> Some toolchain issues would likely fit to the picture as well.
> 
> So provided that there are enough hardware cycles to spare for a separate
> run (i.e. not as part of the frequent Anita runs), maybe something like:
> 
>       1. Install via Anita and verify that the boot is ok.
>          (With source sets or alternatively, fetch the sets from ftp.)

Both sysinst and anita recently gained support for installing the
source sets, so that part is now easy.

>       2. Build the source and verify that the build is ok.

Doing this in qemu will be quite slow.  A full system build takes
about 12000 seconds of CPU on the TNF test machine; I'm not sure what
the qemu slowdown factor is, but I would guess 10-20x, so we're
looking at 120000-240000 seconds, or 33 to 66 hours.

I have a version of Anita (not yet released) that will support
installation in a Xen domU instead of qemu.  That could speed things
up quite a bit if we can find a volunteer to maintain a Xen-based test
environment (not me).

>       3. Install the sources and verify that the second boot is ok.

Presumably you mean "install the binaries"?

> Is this possible with Anita and what would be required?

Anita could be part of the solution.  I think the main things missing
are:

 - Some shell scripts that run build.sh under anita, export the
   resulting release files from a qemu VM disk image to the host
   system, and run anita again with the new release

 - Hardware to run it on; the important parameter is single-threaded CPU
   performance (qemu is single threaded, and I doubt the Xen MP support
   is mature enough to use for this)

 - A volunteer with a lot of patience to set things up.

Given that we already know this test will fail, could you clarify what
the goal of the exercise is?  Is it to detect future regressions after
the present one has been fixed, or are you perhaps thinking of doing
automated bisection to help find the cause of the present regression?
-- 
Andreas Gustafsson, gson%gson.org@localhost


Home | Main Index | Thread Index | Old Index