linux-kernel - Re: [PATCH 14/22] rust: add pin-init crate build infrastructure

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: <D88BLHENDH8Y.HQUKEXN1XB7C@proton.me>
Date: Wed, 05 Mar 2025 12:10:20 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: 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>, Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH 14/22] rust: add pin-init crate build infrastructure

On Wed Mar 5, 2025 at 12:59 PM CET, Andreas Hindborg wrote:
> "Benno Lossin" <benno.lossin@...ton.me> writes:
>
>> From: Miguel Ojeda <ojeda@...nel.org>
>>
>> Add infrastructure for moving the initialization API to its own crate.
>> Covers all make targets such as `rust-analyzer` and `rustdoc`. The tests
>> of pin-init are not added to `rusttest`, as they are already tested in
>> the user-space repository [1].
>
> If it's not too much hassle, why not add them in the kernel as well? I
> would rather not have to go fetch the user space repo from github, in
> the event that I ever need to patch pin-init.

I tried to add them, but encountered a lot of problems. Maybe the new
build system can help with that. But if you insist, I can try to get
them to work again in a different series now.

The tests run every day in the GitHub CI and any changes that go through
the pin-init-next tree will also be tested there before I submit any
PRs.

>> Link: https://github.com/Rust-for-Linux/pin-init [1]
>> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>
>> Co-developed-by: Benno Lossin <benno.lossin@...ton.me>
>> Signed-off-by: Benno Lossin <benno.lossin@...ton.me>
>> ---
>>  rust/Makefile                      | 75 +++++++++++++++++++++++-------
>>  rust/pin-init/internal/src/_lib.rs |  3 ++
>>  rust/pin-init/internal/src/lib.rs  |  4 ++
>>  rust/pin-init/src/_lib.rs          |  5 ++
>>  scripts/Makefile.build             |  2 +-
>>  scripts/generate_rust_analyzer.py  | 17 ++++++-
>>  6 files changed, 86 insertions(+), 20 deletions(-)
>>  create mode 100644 rust/pin-init/internal/src/_lib.rs
>>  create mode 100644 rust/pin-init/src/_lib.rs
>>
>> diff --git a/rust/Makefile b/rust/Makefile
>> index ea3849eb78f6..90310f0620eb 100644
>> --- a/rust/Makefile
>> +++ b/rust/Makefile
>
> [...]
>
>> @@ -110,11 +113,24 @@ rustdoc-compiler_builtins: $(src)/compiler_builtins.rs rustdoc-core FORCE
>>  rustdoc-ffi: $(src)/ffi.rs rustdoc-core FORCE
>>  	+$(call if_changed,rustdoc)
>>
>> -rustdoc-kernel: private rustc_target_flags = --extern ffi \
>> +rustdoc-pin_init_internal: private rustdoc_host = yes
>> +rustdoc-pin_init_internal: private rustc_target_flags = --cfg kernel \
>> +    --extern proc_macro --crate-type proc-macro
>> +rustdoc-pin_init_internal: $(src)/pin-init/internal/src/_lib.rs FORCE
>> +	+$(call if_changed,rustdoc)
>> +
>> +rustdoc-pin_init: private rustdoc_host = yes
>> +rustdoc-pin_init: private rustc_target_flags = --extern pin_init_internal \
>> +    --extern macros --extern alloc --cfg kernel --cfg feature=\"alloc\"
>> +rustdoc-pin_init: $(src)/pin-init/src/_lib.rs rustdoc-pin_init_internal \
>> +    rustdoc-macros FORCE
>> +	+$(call if_changed,rustdoc)
>
> Is it possible to do some code sharing here, such that when we add a
> crate, it's just a matter of putting the path/name on a list somewhere?

Miguel informed me that this Makefile won't exist in the new build
system, so I'd rather not do that.

---
Cheers,
Benno