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

Nathan Chancellor <[email protected]>
Newsgroups gmane.linux.kbuild.devel,gmane.linux.uml.devel,gmane.linux.ports.arm.kernel,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.kernel.rust
Message-ID <20260326024226.GB2302780@ax162>
On Sun, Mar 22, 2026 at 08:21:59PM +0100, Miguel Ojeda wrote:
>   - Clang passes `-Werror=unused-command-line-argument`, which means
>     under arm (i.e. 32-bit) we get:
> 
>       clang: error: argument unused during compilation: '-U arm' [-Werror,-Wunused-command-line-argument]
> 
>     And under UML I see:
> 
>       clang: error: argument unused during compilation: '-I ./arch/um/include/shared' [-Werror,-Wunused-command-line-argument]
>       clang: error: argument unused during compilation: '-I ./arch/x86/um/shared' [-Werror,-Wunused-command-line-argument]
>       clang: error: argument unused during compilation: '-I ./arch/um/include/shared/skas' [-Werror,-Wunused-command-line-argument]
> 
>     So we would need e.g. `-Wno-unused-command-line-argument` there
>     close to the `-Wno-override-module` one, unless Kbuild or
>     ClangBuiltLinux thinks it is important to keep it for this case.

No, I don't think it is worth trying to make -Wunused-command-line-argument
work for this command. Just disable it. This mirrors what is being done
for cmd_cc_o_bc in the distributed ThinLTO:

  https://lore.kernel.org/[email protected]/

>     On the other hand, regardless of whether we fix this (and another
>     issue in a separate email found thanks to the UML build), we could
>     instead add `depends on` listing explicitly the architectures where
>     this is going to be actually tested. That way maintainers can decide
>     whether they want to support it when they are ready. Thoughts?
> 
>     Cc'ing Nathan, Nicolas, Nick, Bill, Justin, David, UML, ARM.

I do agree with some of the concerns that adding an architecure
dimension to this is a little complicated. I would rather try to flush
out those build problems with patches and keep it enabled for all
architectures. At the same time though, I understand that enabling it
for the "tier 1" architectures is a low barrier of entry for getting the
feature upstream, validated, and distributed to the majority of people
that would actually use and depend on it, so I ultimately leave that
call up to you.

>   - If we use the `.bc` extension, we need to add a `.gitignore` for
>     `.bc` files, and an exception for `kernel/time/timeconst.bc`.
> 
>     I guess we will not have too many `bc` scripts in the future for
>     that to be a problem. On the other hand, we have the chance to use
>     another extension (either for LLVM bitcode or for `bc` scripts).
> 
>     But please let me know on e.g. the Kbuild side if someone has
>     concerns...

No real concern on that front but .gitignore has a command to run when
modifying it, which will require a !timeconst.bc in a
kernel/time/.gitignore file.

Cheers,
Nathan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.