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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

I'm going to reply to this email twice.  This email is about the
requirement in my document that the board is supported by Debian
-backports kernels, at least.

I'm replying to two mail@: first Julien's; then Stefano's.


Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition"):
> Most of the time, the issue to boot Debian is related to the kernel. 
> Yet, the price might be too high for some of the vendors to donate the 
> hardware. [...]
> 
> I still want to encourage vendor to work upstream but I would relax the 
> requirements here to "Xen Arm kernel branch".

When you say `I would relax the requirements' you seem to be under the
impression that this requirement is here for some kind of
sociopolitical reason.  It is not, or at least, not only.

It is an actual requirement stemming from the way that osstest does
its host installs (for both builds and tests).

To build a kernel from source code involves an OS install that can be
used for the kernel build, since otherwise there is nowhere to do the
build.

Clearly we do not want to manually create master build environment
images, or have some kind of manually-updated build host.  I certainly
don't have time to maintain such a thing.  Everything must be
automated.

Nor should the approach to setting up a build environment involve
uncontrolled downloading of a pile of varying binaries from various
bits of the internet (eg, a dockerfile).  We need a single reliable
and reputable place where we get the binaries for the base image, so
that we have some idea what is going on and to eliminate or at least
minimise uncontrolled and untracked changes to the test environment.

Currently that one place we get those binaries is a Debian release
(possibly a -backports kernel) and the files are the Debian installer,
Debian kernel, and the Debian binary packages from the Debian archive.
So the builds are done on a Debian host.

This doesn't, in principle, have to be Debian.

Take FreeBSD.  It can only be built on FreeBSD and for complicated
reasons a suitable precooked binary installer is not available.  So
for FreeBSD we make our own image using the previous FreeBSD image, in
a kind of chicken-and-egg setup.  This is quite complicated, and still
does not work entirely right because all the inter-repo dependencies
are apparently not captured properly yet in osstest's automation.

I would be open to doing something similar for ARM but someone would
have to write the code.


> While I understand this point, I think this is going to limit us a lot 
> on the choice of hardware for Arm. While Debian is quite famous on the 
> Server world, this is less the case on the automotive/embedded world 
> where they tend to have there custom distribution.

Obviously I'll take your word for that, although Debian (and its
ecosystem) is also widely used in embedded contexts.

In any case using the hardware vendor's "custom distribution" is
unmanageable for a CI system, even if we were willing to go that far
in the direction of testing using un-upstreamed (and perhaps
un-upstreamable) code.  We can't cope with one OS per kind of board.

I am open to supporting other operating systems as the baseline for
builds and tests.  FreeBSD contributors are already working on support
for that in osstest, on x86 at least.

(I didn't just use Debian because I'm familiar with it.  Debian is
simply much more mature and tractable than most of the alternatives.
It has excellent autoinstallation support, a very high level of
organisation including corresponding source code availability and
excellent release management.  It has wide architecture support and
generally wide support for a large variety of use cases.  From a
community point of view it is welcoming and helpful.  And over the
years it has been a good partner for the Xen Project.  For all I know
many of these things are true of Yocto.)


Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition"):
> That's right, it's a Yocto world around here. That's also what EPAM
> uses.

I am not against using Yocto but I know nothing about it.

Is Yocto a binary distribution, or is it source code ?  Does it do
releases ?

Is the plan then to write code to make osstest install its build hosts
using Yocto ?  Or is the proposal just to use a kernel from Yocto ?
Would we want to do that for all ARM hosts ?

Who will write this code and who will fix it when it goes wrong ?


> > I still want to encourage vendor to work upstream but I would relax the
> > requirements here to "Xen Arm kernel branch".
> 
> +1

I am very open to this.

It does need a solution to the chicken-and-egg problem.  As I say, the
required underlying concepts (for using an existing properly anointed
egg to raise a new chicken so as to generate the next egg) are in
osstest already.

Ie perhaps we could install our build hosts with a Linux image we
prepared earlier.  We would pick up our own-built Linux images, and
when they pass the tests, anoint them for use in future installs.

ISTM that this would be a fairly easy way to improve this area.  If
someone wants to write the actual code to do this I would be very
happy to help with design, advice, review, etc., as I did for the
FreeBSD support (which introduced the anointed-previous-build
concept).

If you are interested then please do say and we can have a
conversation about technical details.


> Xilinx MPSoC support is upstream in vanilla Linux (defconfig), and the
> MPSoC is fully supported in Yocto. We did issue a ticket in the Debian
> system to add support for the Xilinx MPSoC in their kernel but is hasn't
> happened yet. (The fact that Debian support hasn't come up as an issue
> up until now tells us that embedded folks tend to use other distros.)

Can you please point me to the corresponding Debian bug ?

> In general, I think vanilla Linux kernel support would be a rather
> strict requirement for many embedded boards (especially the sub 100$
> ones), but it would still be better than asking for Debian kernel
> support.

Debian is generally willing to backport hardware-support patches from
(say) linux master to its released and -backports kernels.

> Overall, Julien's suggestion to require "Xen Arm kernel branch" is best.

See my discussion above.  This requirement is not just policy; without
it, osstest cannot function because it can't build anything: so it
couldn't build the Xen ARM kernel branch because it would have no host
to build it on until it had built it.


So overall, for the reasons I explain, I'm going to commit this
document (subject to the other comments etc.) *with* the requirement
that hardware must be supported by Debian (at least, in -backports).

If someone wants to do the work to relax that requirement, and to be
around to fix it when things go wrong, then I would be very happy to
help and support that and then this requirements document can be
amended to reflect whatever the new reality is.

I have tried to be clear about this need throughout our past
discussions, ever since we have been trying to acquire more ARM
hardware for the test lab.  I have also tried to be clear in my offers
to accept contributions to change the way things work.

I guess at least stating it again so explicitly and unambiguously in a
high-profile document may produce a different outcome this time.


Ian.

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