On Fri, Feb 14, 2025 at 5:10 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
>
> This will become more important once we have more than just wrappers,
> but I think we should talk about what this will need to look like before
> it actually happens. ie: unstable rust branch tracking unstable c
> branch with build emails, etc? Early days yet, though.
Like an equivalent to the `mm-unstable` one? Would patches only be
promoted if they pass the Rust build etc.?
(Sorry, I don't mind to interfere -- just trying to understand how it
would work, since I may be able to use as an example later on for
other subsystems etc.)
> I am unclear how the branching/merging happens. When do we need to
> start (at lest) building the rust side? We've been doing a lot of work
> in the modularization/interface level to try and integrate more isolated
> testing, as well as the locking changes.
>
> Do you have build bots that will tell us when things are broken?
If you mean on the Rust side, I just wrote some context on another thread:
https://lore.kernel.org/rust-for-linux/CANiq72=Yy8e=pGA+bUHPZhn+D66TmU3kLSjAXCSQzgseSYnDxQ@xxxxxxxxxxxxxx/
The important bit is:
I regularly test different combinations (branches, configs, compiler
versions, and so on) to catch mainly toolchain issues and so on, and
keep things as clean as I can. Others use regularly the Rust support
for their different use cases, thus more testing happens on different
environments. In other words, things generally work just fine.
However, our testing is not meant to catch every issue everywhere.
Like for anything else in the kernel, whoever maintains a branch with
a particular Rust feature needs to set up proper testing for that
particular feature and relevant configs.
I hope that clarifies.
Moreover, there are some bots available that support Rust, e.g.
Intel's 0-day bot. I am happy to put you in contact with them to see
what they can do for your branches.
Cheers,
Miguel
