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

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

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.