linux-kernel - Re: [PATCH] rust: query the compiler for dylib path

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: <CANiq72kzEdyQYhsw10h7qVaT2d=0z1qKsOUo-NzZw5xYrn1nuw@mail.gmail.com>
Date: Sun, 13 Oct 2024 01:37:35 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Tamir Duberstein <tamird@...il.com>
Cc: Daniel Gomez <da.gomez@...sung.com>, rust-for-linux@...r.kernel.org, 
	Fiona Behrens <me@...enk.dev>, Masahiro Yamada <masahiroy@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, 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@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	"David S. Miller" <davem@...emloft.net>, Kris Van Hees <kris.van.hees@...cle.com>, 
	Íñigo Huguet <ihuguet@...hat.com>, 
	Thomas Weißschuh <linux@...ssschuh.net>, 
	Vegard Nossum <vegard.nossum@...cle.com>, 
	Laurent Pinchart <laurent.pinchart@...asonboard.com>, linux-kernel@...r.kernel.org, 
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] rust: query the compiler for dylib path

On Sat, Oct 12, 2024 at 4:25 PM Tamir Duberstein <tamird@...il.com> wrote:
>
> In order for this to be reasonably maintainable we'd want the variable
> to be something like DYLIB_SUFFIX so that we don't have to revisit this
> if macros are ever provided by more than one crate (or worse, have to
> provide N variables).

That is reasonable, and in this it is probably the right approach
since the complexity is similar, but I wanted to clarify that, in the
kernel, revisiting is fine and expected (features are generally not
added if they are not used or expected to be used very soon, so
revisiting to add a more complex feature later is the normal
approach).

But before we do that, is there a way to force `rustc` to load current
name (or trick it to do so, say, with a symlink)? i.e. can it be
reasonably done out-of-tree without changes to the filename?

Thanks!

Cheers,
Miguel