> I am just curious, why would someone want (or not) to do this? This help > text does not really indicate the point of the option, just what it > does. Is it just the standard tradeoffs with inlining (potential > improvements in performance due to better optimization opportunities > versus text size increase and icache pressure) or something else?
The main situations where someone would want this off are: * Not using `clang` (should already be covered in config logic) * Out of tree module build without the whole kernel build tree (the `.bc` file produced here would need to be shipped to your out-of-tree module build environment - it essentially becomes like a header file for purposes of building an out-of-tree / DKMS Rust module) * Don't have matching `rustc` and `clang` LLVM (kind of covered in config logic - if anyone is using a non-release version of LLVM, the config may indicate them as compatible incorrectly). * Requires out-of-tree / DKMS Rust modules to build with the same LLVM revision as the kernel was built with - may be a packaging concern While the usual inlining tradeoffs apply, all of these functions have been explicitly marked `static inline`, which indicates those tradeoffs have already been thought through. I think that if we had a reliable signal of "`clang` and `rustc` use compatible bitcode", turning this on by default would be reasonable. As-is, we have a mostly-reliable signal, so defaulting it to off seems reasonable so that people don't get surprise miscompilations if they use a `clang` or `rustc` which are not using precisely a release-boundary LLVM version. People who know their toolchain story for x-lang is squared away can turn it on. > > Cheers, > Nathan
