On Mon Mar 23, 2026 at 12:54 PM GMT, Andrew Lunn wrote:

On Mon, Mar 23, 2026 at 04:24:59AM +0100, Miguel Ojeda wrote:

quoted

On Mon, Mar 23, 2026 at 4:04 AM Andrew Lunn [off-list ref] wrote:

quoted

Rust is already fragmented, because it does not support all
architectures. Do we really want to make it even more fragmented by
having some bindings only work on a subset of the subset of
architectures?

That is not the case. The `depends on` is not about putting them on
abstractions, but on this experimental build feature, which is gated
on `EXPERT` to begin with, because it uses a fairly exotic approach
involving LLVM bitcode, which carries potential pitfalls, like the
mismatches on the target string like one of the commit messages
mentions, and possibly others.

I'm not sure i follow this.

Maybe i should ask a different question.

You said:

quoted

we
may want to start simple with x86_64 and arm64 or similar first.

The current proposed code for netlink needs this feature, because it
needs access to inline C functions. Is the implication, following a
chain of dependencies, that netlink would only build on x86_64 and
arm64?

If you want netlink on um, arm32, riscv, loongarch you would need a
different implementation of the binding?

It doesn't need this feature to build and function. It'll just be a bit slower
because inlining from C to Rust won't happen.

And a completely different question. Are there other work in progress
solutions to allow the use of inline C functions? For networking, in
particularly MAC and protocol code, anything which needs to access a
struct sk_buf, a solution to this problem will be required. Do you see
this "fairly exotic approach" as just a sort term bridge until some
other "boring approach" is ready?

The actually inlining itself is not exotic, it's exactly same as LTO, just in
smaller scale. Although, the way we do it is probably somewhat uncommon due all
the constraints that the kernel has (mostly due to loadable modules, so we
cannot perform a global LTO and thus need custom handling of LLVM bitcode).

Best,
Gary