Re: Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
Andrew Lunn <[email protected]>
| Newsgroups | gmane.linux.uml.devel,gmane.linux.ports.arm.kernel,gmane.linux.kbuild.devel,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.kernel.rust |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Mar 23, 2026 at 04:24:59AM +0100, Miguel Ojeda wrote: > On Mon, Mar 23, 2026 at 4:04 AM Andrew Lunn <[email protected]> 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? 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? Andrew