References: <20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net>
 <87pm9v9rmg.fsf@metaspace.dk>
 <96cb824e-8251-a329-11e5-3618a4e59bc8@asahilina.net>
User-agent: mu4e 1.9.18; emacs 28.2.50
From:   Andreas Hindborg <nmi@metaspace.dk>
To:     Asahi Lina <lina@asahilina.net>
Cc:     Miguel Ojeda <ojeda@kernel.org>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Wedson Almeida Filho <wedsonaf@gmail.com>,
        Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
        =?utf-8?Q?Bj=C3=B6rn?= Roy Baron <bjorn3_gh@protonmail.com>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Nicolas Schier <nicolas@fjasle.eu>,
        rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-kbuild@vger.kernel.org, asahi@lists.linux.dev
Subject: Re: [PATCH] rust: Enable the new_uninit feature for kernel and
 driver crates
Date:   Mon, 27 Feb 2023 15:34:38 +0100
In-reply-to: <96cb824e-8251-a329-11e5-3618a4e59bc8@asahilina.net>
Message-ID: <875ybn9nsx.fsf@metaspace.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


Asahi Lina <lina@asahilina.net> writes:

> On 27/02/2023 22.09, Andreas Hindborg wrote:
>>=20
>> Asahi Lina <lina@asahilina.net> writes:
>>=20
>>> The unstable new_uninit feature enables various library APIs to create
>>> uninitialized containers, such as `Box::assume_init()`. This is
>>> necessary to build abstractions that directly initialize memory at the
>>> target location, instead of doing copies through the stack.
>>>
>>> Will be used by the DRM scheduler abstraction in the kernel crate, and
>>> by field-wise initialization (e.g. using `place!()` or a future
>>> replacement macro which may itself live in `kernel`) in driver crates.
>>>
>>> See [1] [2] [3] for background information.
>>>
>>> [1] https://github.com/Rust-for-Linux/linux/issues/879
>>> [2] https://github.com/Rust-for-Linux/linux/issues/2
>>> [3] https://github.com/rust-lang/rust/issues/63291
>>>
>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>> ---
>>>  rust/kernel/lib.rs     | 1 +
>>>  scripts/Makefile.build | 2 +-
>>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
>>> index 223564f9f0cc..1118cd3e0b5f 100644
>>> --- a/rust/kernel/lib.rs
>>> +++ b/rust/kernel/lib.rs
>>> @@ -17,6 +17,7 @@
>>>  #![feature(core_ffi_c)]
>>>  #![feature(dispatch_from_dyn)]
>>>  #![feature(generic_associated_types)]
>>> +#![feature(new_uninit)]
>>>  #![feature(receiver_trait)]
>>>  #![feature(unsize)]
>>>=20=20
>>> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
>>> index a0d5c6cca76d..0f637e1ca8dc 100644
>>> --- a/scripts/Makefile.build
>>> +++ b/scripts/Makefile.build
>>> @@ -277,7 +277,7 @@ $(obj)/%.lst: $(src)/%.c FORCE
>>>  # Compile Rust sources (.rs)
>>>  # --------------------------------------------------------------------=
-------
>>>=20=20
>>> -rust_allowed_features :=3D core_ffi_c
>>> +rust_allowed_features :=3D core_ffi_c,new_uninit
>>=20
>> What is the purpose of adding the feature here? The kernel crate seems
>> to compile fine without this.
>
> It's for the upcoming DRM abstractions, as I mentioned in the commit
> message. There's so many dependencies that I'm trying to get as much as
> I can early to avoid having to review very big patchsets down the line ^^

I got confused on the different makefile rules used to build kernel
crate vs module crates. Looks good =F0=9F=91=8D

Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>