Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO

[Gary Guo]

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:
>> On Mon, Mar 23, 2026 at 4:04 AM Andrew Lunn <andrew@xxxxxxx> wrote:
>> >
>> > 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:
>
>> 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