Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
Alice Ryhl <[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 02:28:25PM +0100, Andrew Lunn wrote: > > > 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. > > So it sounds like my understanding is out of date. When the first > Ethernet PHY driver was being merged, Rust could not access inline C > functions. The binding had to replicate the functionality. But you are > saying that Rust can now make use of inline C code, but not actually > inline it? It results in a function call? > > What this feature does it actually allows inline C functions to be > inline? So it is just an optimisation? That's right, this series applies cross-language inlining to the helpers we have for calling inline functions. Sorry if I was unclear on the netlink patch series. I mentioned this series because you told me that inlining is important for skbuff due to performance (not for netlink though), and this series is necessary to make such code on par with C perf-wise. But if you accept the function call overhead from not having cross-language inlining, this series is not needed. Alice