On Tue, Aug 20, 2024 at 7:20 AM Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > I had some feedback on v2 -- was it missed? > > https://lore.kernel.org/rust-for-linux/CANiq72khUrha-a+59KYZgc63w-3P9=Dp_fs=+sgmV_A17q+PTA@xxxxxxxxxxxxxx/ Sorry, I did miss that in the refresh. To respond to a few points before I send up a replacement for this patch: >> >> 1. `rustc` support will soon be a minimum rather than a pinned version. > In the meantime, this happened, so we should update this sentence. Will update. >> 2. We already support multiple LLVMs linked into `rustc`, and these are > I guess you mean `rustc` is able to use multiple major versions of > LLVM -- or what do you mean by "multiple LLVMs linked"? I meant that the `rustc` consumed by the kernel build may use a wide range of different LLVMs, including unreleased ones. This means that which options are valid fundamentally needs to be probed - there's not necessarily a clean "LLVM version" for us to use. I'll rephrase. >> +# $(rustc-option,<flag>) >> +# Return y if the Rust compiler supports <flag>, n otherwise >> +# Calls to this should be guarded so that they are not evaluated if >> +# CONFIG_HAVE_RUST is not set. >Hmm... why `HAVE_RUST`? Should that be `RUST_IS_AVAILABLE`? Or what is t>he intention? Perhaps a comment would help here -- e.g. something >like the comment I used in the original approach [1]. Otherwise we >will forget... :) Yes, this should be RUST_IS_AVAILABLE, will update. >Also, I guess you wanted to relax the precondition as much as >possible, which is great, just to double check, do we expect a case >outside `RUST=y`? I expect this to be potentially used for whether you're *allowed* to set `RUST=y` - for example, if a particular sanitizer is enabled, you may need to probe whether Rust+LLVM supports that sanitizer before allowing RUST to be set to y. >> rustc-option = $(success,trap "rm -rf .tmp_$$" EXIT; mkdir .tmp_$$; $(RUSTC) $(1) --crate-type=rlib /dev/null -o .tmp_$$/tmp.rlib) >I also had `out-dir` [1] since, if I remember correctly, `rustc` may >create temporary files in a potentially read-only location even in >this case. OK, I will add that. >> Also, should we do `-Dwarnings` here? I don't think so - I can't think of a case where we'd want to error on a warning from an empty crate (though that may be a failure of imagination.) Do you have an example of a warning we might trip that we'd want to make the build reject an option's availability? > > Thanks! > > Cheers, > Miguel
