Current-Users archive

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

Re: Test failures

On Tue, Mar 06, 2012 at 09:34:37PM +0200, Andreas Gustafsson wrote:
> Jukka Ruohonen wrote:
> > A round-up now that the tests are again running.
> > 
> > (1) Failures in "fs/psshfs/t_psshfs" and "lib/librumphijack/t_tcpip".
> >     The standard error output is:
> > 
> >        rsa_generate_private_key: key generation failed.
> > 
> >     Probably caused by the RNG changes?
> Probably - the automated test server has it narrowed down to the
> following commits:

It's almost certainly the OpenSSL change.  I'll debug tonight.

> > (2) rump is still broken (see "rump/rumpkern/t_vm/uvmwait").
> Yes, ever since the kmem commits of Janary 27.  Lars, when are you
> going to fix this?

I am not sure it's his responsibility to fix it.  I am seeing an ever
increasing burden pushed onto developers to maintain rump, which is
clearly very very useful but is also only about halfway integrated with
the rest of the system source tree and build framework in ways that make
it extremely fragile and hard to maintain.

Rump builds with hardwired values for many kernel options, its own
copies of various kernel source files, its own separate copy of all
the kernel configuration logic hard-coded into its Makefiles (as opposed
to driven by config as for a normal kernel build), its own separate copy
of the kernel startup logic -- all these things have to be tweaked
twice now for many kernel changes, and the tweaking that has to be done
with rump is like what you'd have to do for a Unix kernel c. 1980 rather
than what you have to do for our more modern system that has much more
automation to glue the pieces together.

Unfortunately, I fear this is well beyond a Summer-of-Code project to
fix but it just screams for some kind of targeted fixing.  It's not
really reasonable to expect kernel developers to do everything twice
just because the rump build framework is half done.

Yes, rump is so incredibly useful for testing that it is worth the
pain, but that does not mean the pain is a good thing.


Home | Main Index | Thread Index | Old Index