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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition 
[and 1 more messages]"):
> I am suggesting to use Debian for the installer and rootfs, but to use a
> different kernel for it.

osstest already knows how to do that in principle, because it knows
how to insert a Debian backports kernel into the Debian d-i image.

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

`Source distribution' means that they don't distribute binaries, so
the thing would have to be built from source.  On an x86 host I
guess.  I see no fundamental difficulties with osstest supporting
that, but it would be some work to implement.

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

Right.

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

OK.  So:


I see two possible approaches:

Firstly, chicken-and-egg: Use osstest's `anointed job' mechanism to
chain one Xen ARM kernel build from the next.  (The anointed job
feature in osstest allows a certain build to be declared generally
good for use by other jobs.  The anointment typically takes place at
the end of a push gate flight, when the build job that is being
anointed has been shown to work properly.)

Secondly, cross-compilation on x86.

I think cross-compilation on x86 is probably going to be easier
because it is conceptually simpler.  It also avoids difficulties if
the anointed build should turn out to be broken on some hosts (this
ought to be detected by the push gate system, but...).  And, frankly,
our x86 hardware is a lot faster.

So, assuming the plan is to do cross-compilation on x86.

The prerequisite is obviously an appropriate cross-compiler.  Will the
Debian cross-compilers do ?  If not then maybe this is not the best
approach because otherwise it's not clear where we'll get a suitable
compiler.


If the Debian cross compilers are OK, then I think the necessary
changes to osstest are:

1. Introduce a distinction between the host (GCC terminology: build)
   and target (GCC terminology: host) architectures, in ts-xen-build.
   This includes adding a call to target_install_packages to install
   the cross compiler, and appropriately amending the configure and
   make runes.  Perhaps some of this will want to be in
   Osstest/BuildSupport.pm.  The runvars for build jobs will need to
   be reviewed to decide whether a new runvar is needed or whether
   cross-compilation can be inferred from a currently-unsupported
   combination of runvars (particularly, arch vs., hostflags).

2. Maybe change ts-kernel-build to be able to additionally produce a
   .deb, or cpio full of modules, for use by step 5.  (This should be
   optional, controlled by a runvar, since it probably doubles the
   size of the build output...)

3. Change make*flight and mfi-* to, on ARM, run the existing kernel
   build job on x86 by setting the job runvars appropriately.

4a. Teach the debian-installer driver in Debian.pm how to pick up a
   kernel image from another job.  It would look at a runvar
   dikernelbuildjob or something I guess.

4b. Teach it to pick up a kernel modules from another job and stuff
   them into its installer cpio before use.

4c. Teach it to put the kernel and modules onto the being-installed
   system.

   This would be a variant of, or amendment to, or alternative to,
   Osstest/Debian.pm:di_special_kernel or its call site.  The kernel's
   ability to handle concatenated cpio images may be useful.

   We will want to refactor into a utility library (probably a file
   of shell functions) at least some of the code in
   mg-debian-installer-update for unpicking a kernel .deb (usually
   from -backports) and fishing out the kernel image and the modules,
   and stuffing the modules into an existing installer cpio archive.

   Whatever approach is taking, the modules in the installer must be a
   subset because the whole set of modules is very large and may make
   the initramfs too big to be booted.  See the list of module paths
   in mg-debian-installer-update.

   NB overall there are four aspects to (4): (i) arranging to boot the
   right kernel; (ii) getting the modules into the installer
   environment; and getting both (iii) kernel and (iv) modules into
   the being-installed system.

5. Change make*flight and mfi-* on ARM to add the new runvar so that
   ARM flights use our own kernels rather than Debian's.

6. Review the arrangements for reuse of existing build jobs, to maybe
   reuse ARM kernel builds more often.  Search cr-daily-branch for
   mg-adjust-flight-makexrefs.  Probably, an additional call should be
   added with some appropriate conditions.



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

This is a rather vague statement but basically, yes.  The question is
(i) where would it come from, and (ii) what would the known location
be.

In my proposal above, (i) it would come from a cross compilation
kernel job in the same flight (but maybe reusing the results of an
identical job elsewhere) (ii) the known location is the osstest build
outputs stash for that build job.


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

Maybe they compile their own kernels (or use a Debian derivative,
which is one way of sharing the effort of doing that...)

> > Can you please point me to the corresponding Debian bug ?
> 
> https://salsa.debian.org/kernel-team/linux/merge_requests/67

Hrm, you may want to file a bug in the Debian BTS.  I'm not sure
whether the stable kernel maintainers are the same people.  OTOH it
has only been there 2 weeks and it wouldn't be released until the next
Debian stable update anyway, after which it would probably go to
backports.

Right now the situation with MRs in Salsa is not always ideal;
sometimes it doesn't email the right people.  It would be worth going
to #debian-kernel (on oftc) and checking that you have made your
request via the right channel.


Thanks,
Ian.

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