rust/helpers/cpumask.c | 5 +++ rust/kernel/cpumask.rs | 94 +++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 98 insertions(+), 1 deletion(-)
The kernel provides a number of very useful CPU masks from the C side,
including CPU masks for possible and online CPUs. In particular, these
are very useful when some operation must be done on each CPU (either
each possible CPU or each online CPU, etc). Therefore, it seems to make
sense to add both of these functionalities at once.
Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
---
These patches originated as part of my work on a Rust per-CPU API [1].
Boqun suggested to me that these may make sense to merge separately, and
it does seem like these might be useful beyond the per-CPU work.
[1]: https://lore.kernel.org/rust-for-linux/20251105-rust-percpu-v4-0-984b1470adcb@gmail.com/
---
Mitchell Levy (2):
rust: cpumask: Add a `Cpumask` iterator
rust: cpumask: Add getters for globally defined cpumasks
rust/helpers/cpumask.c | 5 +++
rust/kernel/cpumask.rs | 94 +++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 98 insertions(+), 1 deletion(-)
---
base-commit: f3f6b3664302e16ef1c6b91034a72df5564d6b8a
change-id: 20251105-cpumask-iter-ff0f1a5899b3
Best regards,
--
Mitchell Levy <levymitchell0@gmail.com>
On 11/5/25 3:16 PM, Mitchell Levy wrote: > The kernel provides a number of very useful CPU masks from the C side, > including CPU masks for possible and online CPUs. In particular, these > are very useful when some operation must be done on each CPU (either > each possible CPU or each online CPU, etc). Therefore, it seems to make > sense to add both of these functionalities at once. > > Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> > --- > These patches originated as part of my work on a Rust per-CPU API [1]. > Boqun suggested to me that these may make sense to merge separately, and > it does seem like these might be useful beyond the per-CPU work. > > [1]: https://lore.kernel.org/rust-for-linux/20251105-rust-percpu-v4-0-984b1470adcb@gmail.com/ Even though you are trying to get these two patches merged separately, I think it's best (for reviewers) if you post a patchset that shows these things being used. Otherwise it is potentially too unmoored from reality, and hard to be sure that it's exactly right from a caller's point of view. In this case, just posting that 9-patch series might work, and just say in the cover letter that patches 3 through 9 are not ready for merging. Something like that. I realize that Rust for Linux is being built from scratch right now, but including calling code in a patchset is a really valuable kernel convention that helps validate the code. I say this for the benefit of others who may be reading. :) thanks, -- John Hubbard
On Wed, Nov 05, 2025 at 04:19:36PM -0800, John Hubbard wrote:
> On 11/5/25 3:16 PM, Mitchell Levy wrote:
> > The kernel provides a number of very useful CPU masks from the C side,
> > including CPU masks for possible and online CPUs. In particular, these
> > are very useful when some operation must be done on each CPU (either
> > each possible CPU or each online CPU, etc). Therefore, it seems to make
> > sense to add both of these functionalities at once.
> >
> > Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
> > ---
> > These patches originated as part of my work on a Rust per-CPU API [1].
> > Boqun suggested to me that these may make sense to merge separately, and
> > it does seem like these might be useful beyond the per-CPU work.
> >
> > [1]: https://lore.kernel.org/rust-for-linux/20251105-rust-percpu-v4-0-984b1470adcb@gmail.com/
>
> Even though you are trying to get these two patches merged separately,
> I think it's best (for reviewers) if you post a patchset that shows
> these things being used. Otherwise it is potentially too unmoored from
> reality, and hard to be sure that it's exactly right from a caller's
> point of view.
>
> In this case, just posting that 9-patch series might work, and just
> say in the cover letter that patches 3 through 9 are not ready for
> merging.
>
> Something like that.
>
> I realize that Rust for Linux is being built from scratch right
> now, but including calling code in a patchset is a really valuable
> kernel convention that helps validate the code.
>
> I say this for the benefit of others who may be reading. :)
Not a big deal. Those two patches are self-consistent enough to take
them separately. But I agree that examples are always welcome.
Mitchell, can you resend this small series after addressing my
comments to the big one, and also can you illustrate it with the
usage examples?
Maybe a small test doing:
for cpu in CpuMask::possible_cpus().iter()
ncpus++;
assert_eq!(ncpus == CpuMask::num_possible_cpus());
Thanks,
Yury
On Thu, Nov 06, 2025 at 08:38:54PM -0500, Yury Norov wrote: > On Wed, Nov 05, 2025 at 04:19:36PM -0800, John Hubbard wrote: > > On 11/5/25 3:16 PM, Mitchell Levy wrote: > > > The kernel provides a number of very useful CPU masks from the C side, > > > including CPU masks for possible and online CPUs. In particular, these > > > are very useful when some operation must be done on each CPU (either > > > each possible CPU or each online CPU, etc). Therefore, it seems to make > > > sense to add both of these functionalities at once. > > > > > > Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> > > > --- > > > These patches originated as part of my work on a Rust per-CPU API [1]. > > > Boqun suggested to me that these may make sense to merge separately, and > > > it does seem like these might be useful beyond the per-CPU work. > > > > > > [1]: https://lore.kernel.org/rust-for-linux/20251105-rust-percpu-v4-0-984b1470adcb@gmail.com/ > > > > Even though you are trying to get these two patches merged separately, > > I think it's best (for reviewers) if you post a patchset that shows > > these things being used. Otherwise it is potentially too unmoored from > > reality, and hard to be sure that it's exactly right from a caller's > > point of view. > > > > In this case, just posting that 9-patch series might work, and just > > say in the cover letter that patches 3 through 9 are not ready for > > merging. > > > > Something like that. > > > > I realize that Rust for Linux is being built from scratch right > > now, but including calling code in a patchset is a really valuable > > kernel convention that helps validate the code. > > > > I say this for the benefit of others who may be reading. :) > > Not a big deal. Those two patches are self-consistent enough to take > them separately. But I agree that examples are always welcome. > > Mitchell, can you resend this small series after addressing my > comments to the big one, and also can you illustrate it with the > usage examples? > > Maybe a small test doing: > > for cpu in CpuMask::possible_cpus().iter() > ncpus++; > > assert_eq!(ncpus == CpuMask::num_possible_cpus()); Sure, will do. My current plan is to do rustdoc tests that will double as examples in the generated documentation. However, if you'd prefer something in `samples/rust` instead (or in addition), please let me know. Thanks, Mitchell > Thanks, > Yury
On Fri, Nov 07, 2025 at 03:56:54PM -0800, Mitchell Levy wrote: > On Thu, Nov 06, 2025 at 08:38:54PM -0500, Yury Norov wrote: > > On Wed, Nov 05, 2025 at 04:19:36PM -0800, John Hubbard wrote: > > > On 11/5/25 3:16 PM, Mitchell Levy wrote: > > > > The kernel provides a number of very useful CPU masks from the C side, > > > > including CPU masks for possible and online CPUs. In particular, these > > > > are very useful when some operation must be done on each CPU (either > > > > each possible CPU or each online CPU, etc). Therefore, it seems to make > > > > sense to add both of these functionalities at once. > > > > > > > > Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> > > > > --- > > > > These patches originated as part of my work on a Rust per-CPU API [1]. > > > > Boqun suggested to me that these may make sense to merge separately, and > > > > it does seem like these might be useful beyond the per-CPU work. > > > > > > > > [1]: https://lore.kernel.org/rust-for-linux/20251105-rust-percpu-v4-0-984b1470adcb@gmail.com/ > > > > > > Even though you are trying to get these two patches merged separately, > > > I think it's best (for reviewers) if you post a patchset that shows > > > these things being used. Otherwise it is potentially too unmoored from > > > reality, and hard to be sure that it's exactly right from a caller's > > > point of view. > > > > > > In this case, just posting that 9-patch series might work, and just > > > say in the cover letter that patches 3 through 9 are not ready for > > > merging. > > > > > > Something like that. > > > > > > I realize that Rust for Linux is being built from scratch right > > > now, but including calling code in a patchset is a really valuable > > > kernel convention that helps validate the code. > > > > > > I say this for the benefit of others who may be reading. :) > > > > Not a big deal. Those two patches are self-consistent enough to take > > them separately. But I agree that examples are always welcome. > > > > Mitchell, can you resend this small series after addressing my > > comments to the big one, and also can you illustrate it with the > > usage examples? > > > > Maybe a small test doing: > > > > for cpu in CpuMask::possible_cpus().iter() > > ncpus++; > > > > assert_eq!(ncpus == CpuMask::num_possible_cpus()); > > Sure, will do. My current plan is to do rustdoc tests that will double > as examples in the generated documentation. However, if you'd prefer > something in `samples/rust` instead (or in addition), please let me > know. I like traditional tests. If you do both - even better.
© 2016 - 2026 Red Hat, Inc.