[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ldtjbqw2.fsf@kernel.org>
Date: Wed, 05 Mar 2025 13:31:25 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Benno Lossin" <benno.lossin@...ton.me>
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
"Benno Lossin" <benno.lossin@...ton.me> writes:
> 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.
I _really_ think that the ability to run the tests should be present in
the kernel repository. But I also do not want to block this series on it,
if it is something that will be easier to achieve with the build system
overhaul that is in the pipeline.
>
>>> 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.
OK, cool.
Best regards,
Andreas Hindborg
Powered by blists - more mailing lists