lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72khUrha-a+59KYZgc63w-3P9=Dp_fs=+sgmV_A17q+PTA@mail.gmail.com>
Date: Wed, 14 Aug 2024 13:27:19 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Matthew Maurer <mmaurer@...gle.com>
Cc: dvyukov@...gle.com, ojeda@...nel.org, 
	Masahiro Yamada <masahiroy@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Wedson Almeida Filho <wedsonaf@...il.com>, Nathan Chancellor <nathan@...nel.org>, aliceryhl@...gle.com, 
	samitolvanen@...gle.com, Nicolas Schier <nicolas@...sle.eu>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, 
	llvm@...ts.linux.dev
Subject: Re: [PATCH v2 1/3] kbuild: rust: Define probing macros for rustc

On Tue, Aug 13, 2024 at 1:29 AM Matthew Maurer <mmaurer@...gle.com> wrote:
>
> 1. `rustc` support will soon be a minimum rather than a pinned version.

In the meantime, this happened, so we should update this sentence.

> 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"?

> +# $(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
the intention? Perhaps a comment would help here -- e.g. something
like the comment I used in the original approach [1]. Otherwise we
will forget... :)

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`?

> 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.

Also, should we do `-Dwarnings` here?

> +# If you are testing for unstable features, consider `rustc-min-version`
> +# instead, as features may have different completeness while available.

`rustc-min-version` is not mainline yet -- we don't have a user yet,
but I can send it if so.

Thanks!

[1] https://github.com/Rust-for-Linux/linux/pull/1087#issuecomment-2218445303

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ