[PATCH 0/2] Bitmap bindings for rust

[PATCH 0/2] Bitmap bindings for rust

[Yury Norov]

Hi Viresh, Miguel, Danilo and everyone,

Please review the bindings and a new maintenance entry together with my
understanding of our way to collaborate. I tried to summarize the recent
discussions in patch 2. If you have any thoughts please let me know.

Thanks,
Yury

Viresh Kumar (1):
  rust: Add cpumask helpers

Yury Norov (1):
  bitmap: add rust bindings entry in MAINTAINERS

 MAINTAINERS                     |  5 +++++
 rust/bindings/bindings_helper.h |  1 +
 rust/helpers/cpumask.c          | 40 +++++++++++++++++++++++++++++++++
 rust/helpers/helpers.c          |  1 +
 4 files changed, 47 insertions(+)
 create mode 100644 rust/helpers/cpumask.c

-- 
2.43.0

[PATCH 1/2] rust: Add cpumask helpers

[Yury Norov]

From: Viresh Kumar <viresh.kumar@linaro.org>

In order to prepare for adding Rust abstractions for cpumask, add
the required helpers for inline cpumask functions that cannot be
called by rust code directly.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
---
Yury: a bit more wording in commit description.

Question: zalloc_cpumask_war() is a convenient wrapper around
alloc_cpumask_var_node(). Maybe rust can use the latter directly as it's
a true outlined function? There's more flexibility, if you need it, but
also a higher risk that the API will change: ~40 users vs 180 for zalloc
thing. Up to you guys. I can send v2 if needed.

 rust/bindings/bindings_helper.h |  1 +
 rust/helpers/cpumask.c          | 40 +++++++++++++++++++++++++++++++++
 rust/helpers/helpers.c          |  1 +
 3 files changed, 42 insertions(+)
 create mode 100644 rust/helpers/cpumask.c

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index f46cf3bb7069..2396ca1cf8fb 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -10,6 +10,7 @@
 #include <linux/blk-mq.h>
 #include <linux/blk_types.h>
 #include <linux/blkdev.h>
+#include <linux/cpumask.h>
 #include <linux/cred.h>
 #include <linux/device/faux.h>
 #include <linux/errname.h>
diff --git a/rust/helpers/cpumask.c b/rust/helpers/cpumask.c
new file mode 100644
index 000000000000..df4b1a2853a9
--- /dev/null
+++ b/rust/helpers/cpumask.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/cpumask.h>
+
+void rust_helper_cpumask_set_cpu(unsigned int cpu, struct cpumask *dstp)
+{
+	cpumask_set_cpu(cpu, dstp);
+}
+
+void rust_helper_cpumask_clear_cpu(int cpu, struct cpumask *dstp)
+{
+	cpumask_clear_cpu(cpu, dstp);
+}
+
+void rust_helper_cpumask_setall(struct cpumask *dstp)
+{
+	cpumask_setall(dstp);
+}
+
+unsigned int rust_helper_cpumask_weight(struct cpumask *srcp)
+{
+	return cpumask_weight(srcp);
+}
+
+void rust_helper_cpumask_copy(struct cpumask *dstp, const struct cpumask *srcp)
+{
+	cpumask_copy(dstp, srcp);
+}
+
+bool rust_helper_zalloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
+{
+	return zalloc_cpumask_var(mask, flags);
+}
+
+#ifndef CONFIG_CPUMASK_OFFSTACK
+void rust_helper_free_cpumask_var(cpumask_var_t mask)
+{
+	free_cpumask_var(mask);
+}
+#endif
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 0640b7e115be..de2341cfd917 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -11,6 +11,7 @@
 #include "bug.c"
 #include "build_assert.c"
 #include "build_bug.c"
+#include "cpumask.c"
 #include "cred.c"
 #include "device.c"
 #include "err.c"
-- 
2.43.0

[PATCH 2/2] MAINTAINERS: add rust bindings entry for bitmap API

[Yury Norov]

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

Re: [PATCH 2/2] MAINTAINERS: add rust bindings entry for bitmap API

[Miguel Ojeda]

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

Re: [PATCH 2/2] MAINTAINERS: add rust bindings entry for bitmap API

[Yury Norov]

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

Re: [PATCH 2/2] MAINTAINERS: add rust bindings entry for bitmap API

[Viresh Kumar]

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

Re: [PATCH 1/2] rust: Add cpumask helpers

[Viresh Kumar]

Hi Yury,

On 21-02-25, 15:56, Yury Norov wrote:
> Question: zalloc_cpumask_war() is a convenient wrapper around
> alloc_cpumask_var_node(). Maybe rust can use the latter directly as it's
> a true outlined function? There's more flexibility, if you need it, but
> also a higher risk that the API will change: ~40 users vs 180 for zalloc
> thing. Up to you guys. I can send v2 if needed.

I looked at the APIs again and here is what I feel:

- I am not sure if the Rust code will have any users of the *_node()
  APIs in the near future. i.e. There is no need for the Rust code to
  implement Cpumask::new_node() version for now.

- I have missed implementing the uninitialized version earlier,
  alloc_cpumask_var(), which I think should be implemented right away.
  Bindings for alloc_cpumask_var() are required to be added for this
  though.

- One advantage of using zalloc_cpumask_var() instead of
  alloc_cpumask_var() is that we don't need to open code it in the
  Rust code, specifically for the !CONFIG_CPUMASK_OFFSTACK case where
  we need to call cpumask_clear() separately.

- The Rust side can have following abstractions for now:

  pub fn new() -> Result<Self>;
  pub fn new_zeroed() -> Result<Self>;

-- 
viresh

Re: [PATCH 1/2] rust: Add cpumask helpers

[Yury Norov]

On Mon, Feb 24, 2025 at 02:26:13PM +0530, Viresh Kumar wrote:
> Hi Yury,
> 
> On 21-02-25, 15:56, Yury Norov wrote:
> > Question: zalloc_cpumask_war() is a convenient wrapper around
> > alloc_cpumask_var_node(). Maybe rust can use the latter directly as it's
> > a true outlined function? There's more flexibility, if you need it, but
> > also a higher risk that the API will change: ~40 users vs 180 for zalloc
> > thing. Up to you guys. I can send v2 if needed.
> 
> I looked at the APIs again and here is what I feel:
> 
> - I am not sure if the Rust code will have any users of the *_node()
>   APIs in the near future. i.e. There is no need for the Rust code to
>   implement Cpumask::new_node() version for now.
> 
> - I have missed implementing the uninitialized version earlier,
>   alloc_cpumask_var(), which I think should be implemented right away.
>   Bindings for alloc_cpumask_var() are required to be added for this
>   though.
> 
> - One advantage of using zalloc_cpumask_var() instead of
>   alloc_cpumask_var() is that we don't need to open code it in the
>   Rust code, specifically for the !CONFIG_CPUMASK_OFFSTACK case where
>   we need to call cpumask_clear() separately.
>
> - The Rust side can have following abstractions for now:
> 
>   pub fn new() -> Result<Self>;
>   pub fn new_zeroed() -> Result<Self>;
> 
> -- 
> viresh

OK, if you need both I'll export both. I'll send it in v2 together
with clarifications from discussion with Miguel.
 

[PATCH 2/2] MAINTAINERS: add rust bindings entry for bitmap API

[Yury Norov]

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

This entry enumerates bitmap and related APIs listed in BITMAP API entry
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."

Accordingly, the following policy applies to all interfaces under the
BITMAP API entry that are used in rust codebase, including those not
listed explicitly here.

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 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..315cff76df29 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

Re: [PATCH 2/2] MAINTAINERS: add rust bindings entry for bitmap API

[Viresh Kumar]

On 24-02-25, 18:39, Yury Norov wrote:
> From: "Yury Norov [NVIDIA]" <yury.norov@gmail.com>
> 
> This entry enumerates bitmap and related APIs listed in BITMAP API entry
> 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."
> 
> Accordingly, the following policy applies to all interfaces under the
> BITMAP API entry that are used in rust codebase, including those not
> listed explicitly here.
> 
> 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 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(+)

Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh