Re: Current Eclair analysis

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

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