Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 2 Nov 2018, Ian Jackson wrote:
> > > If the Debian cross compilers are OK, then I think the necessary
> > > changes to osstest are:
> ...
> > I thought that we could have provided a deb repository with alternative
> > kernels for OSSTests to use. We would have scripts to generate those deb
> > packages from the Xen ARM Linux tree in a repository on xenbits, but we
> > wouldn't necessarily have OSSTest run the script. Initially, we could
> > run the scripts by hand, then, we could run them automatically in
> > OSSTest or elsewhere. Is that a possibility? I already have Dockerfiles
> > (AKA bash scripts) to build an ARM kernel on a few distros, that's
> > something I could make available.
> 
> Everything that osstest consumes should either be either:
> (i) snapshotted and push gated, so that osstest always uses a version
>    that it itself has previously tested
> (ii) maintained to a very high standard of quality and availability.
> 
> For things for which we take approach (ii), regressions of any kind,
> or unavailability of the download server, cause what is effectively a
> whole-system outage for osstest: every test run ends up plagued by
> whatever lossage is going on.  Implying no disrespect, but doing (ii)
> for a kernel apt repository is very hard.
> 
> So I think (i) would be more appropriate.  That would mean generating,
> periodically, a whole new apt repository, alongside the old one.
> Presumably they would have the generation date in the filename, like
> our Debian installer images do.  Updating would involve a commit to
> the osstest config file, which is push-gate-controlled.
> 
> Overall I think, though, that this is probably not the best approach.
> 
> What you are saying is that you do not have the effort to automate the
> building of kernel binaries, and instead you propose to do it
> manually.  That seems like a false economy.
> 
> The task of automating the building of kernel binaries is points 1-3
> of my plan to cross build the kernels and use the result for baremetal
> builds; that's not the hardest part.

[...]

> Ie the biggest work here of all kinds is is glue.  Adding more
> entities to the problem will increase rather than reduce the amount of
> glue code that needs to be written.

Basically, you are saying that even if had a well maintained deb
repository of kernel packages for OSSTest to use, doesn't matter how we
achieve this goal, it would still require a non trivial amount of work
to do the integration with OSSTest.

I would have thought that it would have made OSSTest work (almost) out
of the box. Too bad. In that case, I'll leave this thread and the
implementation choices to the people that are actually going to do work
on it.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel