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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>]

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

I am suggesting to use Debian for the installer and rootfs, but to use a
different kernel for it. The kernel could come from the same Xen ARM
kernel branch that we'll use later for dom0 (Julien's suggestion).

Building the kernel could be done in a number of ways we can discuss,
including cross-compiling it on x86 hosts. It is simple to cross-compile
kernels.

The ARM kernel branch won't change very often, we could start by
building Debian packages by hand for it and pushing them to a known
location. OSSTest could fetch the Debian installer kernel from there. I
am sure we could find other, better, ways to do this.


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

Neither Julien nor me are suggesting to use a Vendor's distro, not even
a Vendor's kernel. We are suggesting to use our own kernel branch
together with Debian.

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

Actually, I think it would be great to have Yocto support in OSSTest, it
would work well on ARM and x86 but, also because it is a source
distribution, I am not suggesting it at the moment.

It would be possible to only use the kernel from Yocto, and that would
solve our problem, but at that point it is easier to just use our own
Linux branch. It is more productive to discuss that option.


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

Yes, we should discuss the technical details on how to use our own
quasi-vanilla Linux branch together with the Debian installer. That's
all we need AFAICT.

Could you build and push kernel binary (no required modules) to a known
location?


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

https://salsa.debian.org/kernel-team/linux/merge_requests/67

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