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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition 
[and 1 more messages] [and 2 more messages]"):
> Thank you for the detailed answer and the willingness to see osstest
> changed in this respect.

Sure.  It's not fixed in stone, and a variety of approachs will fit
into it I think.

> Let me premise that as much as I would like this to be done, I had a
> look at my schedule, and, realistically, I can only volunteer very
> little time on this. In regards to the two Xilinx boards, it looks like
> we'll just have to wait for Debian.

OK.  That's perhaps less work overall at our end anyway.  Let me know
if you think any aspect of this is getting stuck somehow; I have
contacts in Debian which I could use to enquire or whatever.

> On Thu, 1 Nov 2018, Ian Jackson wrote:
> > The prerequisite is obviously an appropriate cross-compiler.  Will the
> > Debian cross-compilers do ?
> 
> Probably it would work, but I don't know for sure. Most people use the
> Linaro compiler and toolchain:
> 
> https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/
> https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/

I guess that's probably tolerable.  We'd have to think about whether
we should snapshot them, or install them directly from upstream.  The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us.  Also I would ask: how reliable is their apt
repository hosting ?  If it goes down, likewise, everything would
break for us.

> Testing the Debian cross-compiler would be very easy.

Perhaps Julien has time to do that.

> > 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.

> This morning Julien had one more different suggestion: building the
> kernel with OSSTest on SoftIron, that we know it works, it would be a
> native compilation. Then we could use the built kernel together with the
> Debian installer on the other boards (Xilinx, Renesas, etc.)

Yes, that is also a possibility.  But it still involves steps 4-6 from
my plan.

> Either way, the kernel to be used with the embedded boards doesn't need
> to be rebuilt often, only once a month or so.

Of course we shouldn't waste it, but computer time is much cheaper
than human time.  osstest already has mechanisms to optimise by
reusing builds where appropriate.  The easiest thing is to tell
osstest `we want a kernel built like this' and it will DTRT.

Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more 
messages] [and 2 more messages]"):
>     Either way, the kernel to be used with the embedded boards doesn't need
>     to be rebuilt often, only once a month or so.
>     
> That would fit with the https://gitlab.com/xen-project/xen/container_registry 
> model 
> where we store Dom0 baselines as containers for builds via the Gitlab CI 
> 
> This may be a stupid idea, but I wanted to make sure that we consider all 
> options

I don't know much about this.

I have no objection to osstest consuming things that came out of the
gitlab CI.

We would have to think about whether those things would (by virtue of
their origin) be necessarily of good enough quality, so that osstest
could simply use them, or whether we would want osstest to have a QA
gate before it accepted a new build.

We would also have to think about where these images (or whatever they
are) were hosted: should that be on xenbits or in a test lab VM (for
fate-sharing reasons) ?

But overall I think getting osstest to build these binaries is not the
hardest part.  If we use osstest-built binaries then we can reuse all
the existing push-gate-linked snapshotting and hosting and so on; if
we use externally built binaries we have an integration challenge.

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.


Wei Liu writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more 
messages] [and 2 more messages]"):
> Debian's cross-compiler package conflicts with its native compiler,

Specifically it conflicts with the multilib style native compiler used
for Xen.  This is a bug in Debian but it is intractable because of the
approach of the Debiabn GCC maintainer, so we will have to live with
it.

However, this is not a blocker because osstest could use a dedicated
x86 setup for the ARM cross builds.  That's not ideal because it
shares resources less well, but it's certainly workable.

But maybe we just want to build on ThunderX.  That leaves steps 4-6 of
my plan, which almost any approach (other than fixing the kernels in
Debian) require.

Ian.

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