From: Yury Norov [NVIDIA] <yury.norov@gmail.com>

This entry enumerates all bitmap and related APIs that rust requires
but cannot use directly (i.e. inlined functions and macros).

The "Rust kernel policy" (https://rust-for-linux.com/rust-kernel-policy)
document describes the special status of rust support:

  "Exceptionally, for Rust, a subsystem may allow to temporarily
   break Rust code."

Bitmap developers do their best to keep the API stable. When API or
user-visible behavior needs to be changed such that it breaks rust,
bitmap and rust developers collaborate as follows:
 - bitmap developers don't consider rust bindings as a blocker for the
   API change;
 - bindings maintainer (me) makes sure that kernel build doesn't break
   with CONFIG_RUST=y. This implies fixes in the binding layer, but not
   in the rust codebase;
 - rust developers adopt new version of API in their codebase and remove
   unused bindings timely.

CC: Danilo Krummrich <dakr@redhat.com>
CC: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
CC: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index efee40ea589f..4fb287405492 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4021,6 +4021,11 @@ F:	tools/include/vdso/bits.h
 F:	tools/lib/bitmap.c
 F:	tools/lib/find_bit.c
 
+BITMAP API BINDINGS [RUST]
+M:	Yury Norov <yury.norov@gmail.com>
+S:	Maintained
+F:	rust/helpers/cpumask.c
+
 BITOPS API
 M:	Yury Norov <yury.norov@gmail.com>
 R:	Rasmus Villemoes <linux@rasmusvillemoes.dk>
-- 
2.43.0

On Fri, Feb 21, 2025 at 9:57 PM Yury Norov <yury.norov@gmail.com> wrote:
>
> Bitmap developers do their best to keep the API stable. When API or
> user-visible behavior needs to be changed such that it breaks rust,
> bitmap and rust developers collaborate as follows:

If I understand correctly, you are proposing to a "temporarily stable
API", i.e. to add new APIs while keeping old ones for a bit until the
Rust side updates to the new one (including perhaps workarounds in the
helpers when needed). Is that correct?

In other words, while the entry is about the helpers file, the policy
is about all APIs (since some APIs are called directly), right?

(Up to you, Viresh et al., of course, i.e. I am just trying to follow)

Thanks!

Cheers,
Miguel

On Sat, Feb 22, 2025 at 02:50:50PM +0100, Miguel Ojeda wrote:
> On Fri, Feb 21, 2025 at 9:57 PM Yury Norov <yury.norov@gmail.com> wrote:
> >
> > Bitmap developers do their best to keep the API stable. When API or
> > user-visible behavior needs to be changed such that it breaks rust,
> > bitmap and rust developers collaborate as follows:
> 
> If I understand correctly, you are proposing to a "temporarily stable
> API", i.e. to add new APIs while keeping old ones for a bit until the
> Rust side updates to the new one (including perhaps workarounds in the
> helpers when needed). Is that correct?

Yes. Keeping them under CONFIG_RUST for a while, or moving directly to
rust helpers would be an option.

> In other words, while the entry is about the helpers file, the policy
> is about all APIs (since some APIs are called directly), right?

Yes, it's about all functions used by rust. I can underline it in
the commit message. 
 
> (Up to you, Viresh et al., of course, i.e. I am just trying to follow)

What I want to make clear to my contributors is that lack of proficiency
in rust will never become a problem for them. If they have an improvement
that may break something on rust side, there will be someone who will take
care of it - this way or another.

I think rust developers need similar guarantees form rust maintainers:
there will be a rust engineer who will keep the bindings on rust side in
a good shape. Viresh, as per my understanding, has committed on that.

Thanks,
Yury

On 22-02-25, 18:34, Yury Norov wrote:
> I think rust developers need similar guarantees form rust maintainers:
> there will be a rust engineer who will keep the bindings on rust side in
> a good shape. Viresh, as per my understanding, has committed on that.

Yes.

-- 
viresh