Hi Andrew,
thanks for the feedback, it's very appreciated.
On 2025-12-10 19:14, Andrew Cooper wrote:
Hello,
The Eclair step is now the dominating aspect of wallclock time. While
the recent changes were a step in the right direction, we need some
adjustments.
First, we have *-testing running in all cases, but my understanding was
that that was supposed to be for deploying a new version of Eclair.
Can
we make this be generally off?
Definitely; it was an oversight on my part when testing the patch,
because I used a repo/tree that was supposed to run those *-testing
jobs. As soon as I can find some free time to work on it, I'll
investigate and send a patch, unless someone beats me to it.
Next, jobs are scheduled in the order they appear in the yaml file,
which means the general ARM one goes ahead of the safety target. Just
something to bear in mind as changes are being made.
Well, but the general one should be allocated to the larger runner that
runs both safety and non-safety jobs, so in my opinion this is fine.
When the *-safety jobs start, they'll be picked up by the less powerful
eclair-safety-runner one at a time.
While the x86 runs are non-fatal, having them fail is still gets in the
way of trivially telling that the pipeline is green.
See below for the consideration about clean rules, but the idea is that
we can get rid of most of those fairly quickly. I did glance at most of
those, but the time I have for preparing patches is quite scarce. I see
that Michal has done some work already on Arm; I did share with him a
few half-done patches that I have in a branch of mine [1], and I will
also take a look at the series you just sent.
[1]
https://gitlab.com/xen-project/people/bugseng/xen/-/tree/eclair_pipeline?ref_type=heads
The names, -safety and no suffix are a little problematic, seeing as
everything here is for safety use.
Overall, what I think we want is something more like this:
Jobs named as *-all and *-amd. After all, it's AMD's safety target
specifically, not necessarily someone elses.
Well, depends on how you look at that: the *-safety jobs have a fixed
config, while the configuration for the general Arm and x86 jobs may
vary as Xen changes. That being said, I don't mind changing names
personally; I just went with what seemed more natural at the time.
The *-all targets want everything possible enabling. Ideally we want
something like Linux's COMPILE_TEST, but in the short term we can just
adjust the input Kconfig.
Ack
Like we had with the common configuration and the per-arch
configuration, I think we want to express the clean rules as common,
with a wider (a.k.a stricter) set used for the *-amd target.
The longterm goal is to get the *-all targets as strict as the *-amd
targets, but right now because there are no blocking clean rules, it's
easier for regressions to slip in.
Ack. I tried to start simpler and then iterate based on feedback. Should
be rather easy to craft a configuration doing that.
This brings us back to the debate about the excluded files from
external
sources. They still need fixing one way or another. Do we see about
including them for analysis in the *-all targets, or leave them
excluded
knowing that whomever need to unpack that can of worms needs to do a
lot
of fixing anyway?
I had debated addressing this, but in the end I opted to prioritize
fixes to the violations originating from Xen code. Who wants to qualify
Xen in the end needs to pick features/configurations, so my take is that
everything that is not truly kept in sync with the external source
(e.g., recent discussions about libelf w.r.t XSA-55) should be made
compliant eventually, and then it is on the downstreams to decide on
what to do with respect to external source dependencies in their
usecase. Stricly speaking, they would be subjected to MISRA compliance,
but the point is moot if they are not actually used.
Does this sound sensible?
Thanks,
~Andrew
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
