[Kerncomp-devel] Re: [ANNOUNCE] Automated Kernel Build Regression Testing

[Jan D. <jdi...@pp...>]

Darren Williams wrote:
>>>ls arch/*/configs/* gives about 184 different defconfigs. A test run
>>>on my single workstation would take literally ages. Therefore I'd
>>>consider a distributed client/server approach.
> 
> 
> And not all cross-compilers successfully build the kernel, where as the
> native build would succeed. There have been discussion about this on lkml. 

Though that should be considered a bug (tm). Different output directory
(O=) also does not always work.

> In any simulator, LTP or any other thorough testing would take years, we need
> real hardware, this is my next big project (Autobench/test). This I think
> would be really cool. I think we could get the resources, we just need the
> auto stuff. Looking behind me I see idle sparc, ppc, alpha, 386 .....

So lets get started. Well do you want to coordinate this? I think my
platform would provide an easy start. I just need to split out the server and
client part.
What I plan to implement, hopefully till next weekend, is a system which
discovers new kernel versions and builds a table of kernel/version/arch
triplets that want to be tested.
Against these versions any number of tests can run: compile, run time test,
whatever, ... and report the results back, without much of formal requirements.
Basically a big storage of test results. Would that work out for you?

>>>But I looked at yours, and you're not using a db at all? You're just
>>>using flat files to store the results and parse them afterwards?
>>
>>Yes ... I think this has many advantages such as compressing and
>>archiving the logs, and the fact you can simply rsync things around.
>>I'm not married to it though ...
> 
> 
> And you do not require a dbm, hey we could store the results in a
> Git tree (8-0

... and write git-SELECT to search through them? :) Really sql has lots
of advantages when your store even slightly more complex/relational
things.

Jan