rust/kernel/error.rs | 3 +- rust/kernel/lib.rs | 1 + rust/kernel/once_lite.rs | 127 +++++++++++++++++++++++++++++++++++++++++++++++ rust/kernel/print.rs | 126 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 255 insertions(+), 2 deletions(-)
Add Rust version of pr_[emerg|alert|crit|err|warn|notic|info]_once
functions, which print a message only once.
Introduces a `OnceLite` abstraction similar to Rust's
[`std::sync::Once`](https://doc.rust-lang.org/std/sync/struct.Once.html)
but using the non-blocking mechanism from the kernel's `DO_ONCE_LITE`
macro, which is used to define the `do_once_lite` Rust macro.
First use case are an implementation of `pr_*_once` message macros to
print a message only once.
v4:
- Move `do_once_lite` macro implementation to `OnceLite` abstraction
- Use `OnceLite` in `do_once_lite`
- More documentation, examples
v3: https://lore.kernel.org/rust-for-linux/20241109-pr_once_macros-v3-0-6beb24e0cac8@tuta.io/
- Fix rustdoc error, formatting issues
- Fix missing Signed-off-by
v2: https://lore.kernel.org/r/20241107-pr_once_macros-v2-0-dc0317ff301e@tuta.io
- Split patch into do_once_lite part and pr_*_once macros
- Add macro rule for call without condition => renamed to do_once_lite
- Used condition-less call in pr_*_once macros
- Added examples
- Removed TODO in kernel/error.rs using pr_warn_once
v1: https://lore.kernel.org/rust-for-linux/20241106.083113.356536037967804464.fujita.tomonori@gmail.com/
Co-developed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Co-developed-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Jens Korinth <jens.korinth@tuta.io>
---
FUJITA Tomonori (1):
rust: print: Add pr_*_once macros
Jens Korinth (2):
rust: Add `OnceLite` for executing code once
rust: error: Replace pr_warn by pr_warn_once
rust/kernel/error.rs | 3 +-
rust/kernel/lib.rs | 1 +
rust/kernel/once_lite.rs | 127 +++++++++++++++++++++++++++++++++++++++++++++++
rust/kernel/print.rs | 126 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 255 insertions(+), 2 deletions(-)
---
base-commit: b2603f8ac8217bc59f5c7f248ac248423b9b99cb
change-id: 20241107-pr_once_macros-6438e6f5b923
Best regards,
--
Jens Korinth <jens.korinth@tuta.io>
Hi Jens, "Jens Korinth via B4 Relay" <devnull+jens.korinth.tuta.io@kernel.org> writes: > Add Rust version of pr_[emerg|alert|crit|err|warn|notic|info]_once > functions, which print a message only once. > > Introduces a `OnceLite` abstraction similar to Rust's > [`std::sync::Once`](https://doc.rust-lang.org/std/sync/struct.Once.html) > but using the non-blocking mechanism from the kernel's `DO_ONCE_LITE` > macro, which is used to define the `do_once_lite` Rust macro. > > First use case are an implementation of `pr_*_once` message macros to > print a message only once. > Thanks for the patch! Do you plan on sending a new version? If not, do you mind if I send v5? Best regards, Andreas Hindborg
Hi! > Thanks for the patch! Do you plan on sending a new version? If not, do you mind if I send v5? I think there is currently no consensus on how exactly it should be done (or at least I was confused about that). If you’re actively using the patch please go ahead! Active usage is always the best argument in such cases. Jens 11 Feb 2025 at 16:05 by a.hindborg@kernel.org: > Hi Jens, > > "Jens Korinth via B4 Relay" <devnull+jens.korinth.tuta.io@kernel.org> writes: > >> Add Rust version of pr_[emerg|alert|crit|err|warn|notic|info]_once >> functions, which print a message only once. >> >> Introduces a `OnceLite` abstraction similar to Rust's >> [`std::sync::Once`](https://doc.rust-lang.org/std/sync/struct.Once.html) >> but using the non-blocking mechanism from the kernel's `DO_ONCE_LITE` >> macro, which is used to define the `do_once_lite` Rust macro. >> >> First use case are an implementation of `pr_*_once` message macros to >> print a message only once. >> > > Thanks for the patch! Do you plan on sending a new version? If not, do > you mind if I send v5? > > > Best regards, > Andreas Hindborg > >
<jens.korinth@tuta.io> writes: > Hi! > >> Thanks for the patch! Do you plan on sending a new version? If not, do you mind if I send v5? > > I think there is currently no consensus on how exactly it should be done (or at least I was confused about that). If you’re actively using the patch please go ahead! Active usage is always the best argument in such cases. I was informed this patch set is the correct way to emit a warning in the module_params patch set [1]. I did not follow all the discussion so I am not sure either. But I'll look into the discussion then. Best regards, Andreas Hindborg [1] https://lore.kernel.org/rust-for-linux/20250204-module-params-v3-v5-0-bf5ec2041625@kernel.org/
On Tue, 11 Feb 2025 16:42:25 +0100 Andreas Hindborg <a.hindborg@kernel.org> wrote: > <jens.korinth@tuta.io> writes: > > > Hi! > > > >> Thanks for the patch! Do you plan on sending a new version? If > >>not, do you mind if I send v5? > > > > I think there is currently no consensus on how exactly it should be > > done (or at least I was confused about that). If you’re actively > > using the patch please go ahead! Active usage is always the best > > argument in such cases. > > I was informed this patch set is the correct way to emit a warning in > the module_params patch set [1]. > > I did not follow all the discussion so I am not sure either. But I'll > look into the discussion then. > > > Best regards, > Andreas Hindborg > > > > [1] > https://lore.kernel.org/rust-for-linux/20250204-module-params-v3-v5-0-bf5ec2041625@kernel.org/ > > I have reviewed the patch series from start to finish. I am not using or depending the patch actively but I can send v5 sometime soon (I will have some space next week) if you would like. Regards, Onur
On Thu, Jul 17, 2025 at 07:07:13PM +0300, Onur Özkan wrote: > On Tue, 11 Feb 2025 16:42:25 +0100 > Andreas Hindborg <a.hindborg@kernel.org> wrote: > > > <jens.korinth@tuta.io> writes: > > > > > Hi! > > > > > >> Thanks for the patch! Do you plan on sending a new version? If > > >>not, do you mind if I send v5? > > > > > > I think there is currently no consensus on how exactly it should be > > > done (or at least I was confused about that). If you´re actively > > > using the patch please go ahead! Active usage is always the best > > > argument in such cases. > > > > I was informed this patch set is the correct way to emit a warning in > > the module_params patch set [1]. > > > > I did not follow all the discussion so I am not sure either. But I'll > > look into the discussion then. > > > > > > Best regards, > > Andreas Hindborg > > > > > > > > [1] > > https://lore.kernel.org/rust-for-linux/20250204-module-params-v3-v5-0-bf5ec2041625@kernel.org/ > > > > > > I have reviewed the patch series from start to finish. I am not > using or depending the patch actively but I can send v5 sometime > soon (I will have some space next week) if you would like. > Note that you need to use LKMM atomics [1], and you should really use a 32bit atomic at the beginning. Thanks! There are a few explanations on why we want to avoid use Rust native atomics: https://lwn.net/Articles/993785/ https://lore.kernel.org/rust-for-linux/CAHk-=whkQk=zq5XiMcaU3xj4v69+jyoP-y6Sywhq-TvxSSvfEA@mail.gmail.com/ [1]: https://lore.kernel.org/rust-for-linux/20250719030827.61357-1-boqun.feng@gmail.com/ Regards, Boqun > Regards, > Onur
On Fri, 18 Jul 2025 20:33:21 -0700 Boqun Feng <boqun.feng@gmail.com> wrote: > > > > I have reviewed the patch series from start to finish. I am not > > using or depending the patch actively but I can send v5 sometime > > soon (I will have some space next week) if you would like. > > > > Note that you need to use LKMM atomics [1], and you should really use > a 32bit atomic at the beginning. Thanks! > > There are a few explanations on why we want to avoid use Rust native > atomics: > > https://lwn.net/Articles/993785/ > https://lore.kernel.org/rust-for-linux/CAHk-=whkQk=zq5XiMcaU3xj4v69+jyoP-y6Sywhq-TvxSSvfEA@mail.gmail.com/ > These are excellent sources for digging into the details. Thanks a lot! :) Regards, Onur
On Tue, Nov 26, 2024 at 5:41 PM Jens Korinth via B4 Relay <devnull+jens.korinth.tuta.io@kernel.org> wrote: > > Co-developed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> > Co-developed-by: Boqun Feng <boqun.feng@gmail.com> > Signed-off-by: Jens Korinth <jens.korinth@tuta.io> I guess these tags are meant to be informative, but just in case, I thought I would ask if they are here for some other reason, i.e. if you somehow want them to end in the kernel log. (It may be less confusing to simply mention in the letter who worked on what.) Cheers, Miguel
© 2016 - 2026 Red Hat, Inc.