ur feedback. I can spend some time investigating
> alternative approaches if they seem worthwhile. I'd be interested to
> know what others think of this too.
You're welcome! I hope that helped at least.
Cc'ing David/Rae/Shuah as well for the KUnit bits.
Cheers,
Miguel
ext.
Thanks!
Cheers,
Miguel
el too).
I have sent a patch for that here:
https://lore.kernel.org/rust-for-linux/20250816211900.2731720-1-oj...@kernel.org/
Cheers,
Miguel
ate.
This still maintains the support for the `macros` crate, even though we
do not have any such tests there.
Link:
https://lore.kernel.org/rust-for-linux/CABVgOS=AKHSfifp0S68K3jgNZAkALBr=7iFb=niryg5wdxj...@mail.gmail.com/
[1]
Signed-off-by: Miguel Ojeda
---
rust/Makefile| 9 +
t very pretty, but it's possible for now.
>
> Cc: Miguel Ojeda
Thanks for the ping -- Cc'ing as well Andreas who is working on module
bits lately (but is away right now) and Danilo who maintains the
modified file:
Cc: Andreas Hindborg
Cc: Danilo Krummrich
Cheers,
Miguel
On Thu, May 29, 2025 at 3:15 PM Tamir Duberstein wrote:
>
> Please see individual commit messages.
>
> Signed-off-by: Tamir Duberstein
Applied to `rust-next` -- thanks everyone!
[ Reworded title. - Miguel ]
[ Kept newlines using `writeln!`. Used new message from Tam
On Thu, May 29, 2025 at 3:15 PM Tamir Duberstein wrote:
>
> +write!(&mut candidates, "{path:?}").unwrap();
I assume this was supposed to be `writeln!`; otherwise, we lose the
newlines and the indent does not make much sense.
I will fix it when applying.
Cheers,
Miguel
happened to
invent an attribute which requires using "auto" in it, since it is not
reserved there in C23 AFAIU. So FWIW:
Acked-by: Miguel Ojeda
> + * so it has always been "namespace reserved."
Not sure what this means (could we just say reserved?).
Thanks!
Relatedly,
>From our discussion in Zulip: the code itself is older than that the
merge above. I think you wanted an example sentence for this --
something simple could be e.g.
Based on the original module parameter support by Miguel [1],
later extended and generalized by Adam for more types [2][3].
Origin
On Wed, Jul 2, 2025 at 8:47 PM Benno Lossin wrote:
>
> @Miguel are you going to pick this eventually, or do you think it should
> have a new version with the right splitting?
I guess I could take it since the series can only introduce build
failures at worst.
However, I thought we were
old so I would suggest taking a look
at naming etc. with fresh eyes.
Cheers,
Miguel
On Tue, Jul 1, 2025 at 5:43 PM Benno Lossin wrote:
>
> Ultimately this is something for Miguel to decide.
Only if you all cannot get to an agreement ;)
If Andreas wants to have it already added, then I would say just mark
it `unsafe` as Benno recommends (possibly with an overb
but if you do, then please
reword it).
Cheers,
Miguel
, maintainers still have to
coordinate, which isn't a big deal, since the changes are small and
straightforward, but the purpose of the split was to avoid that.
Cheers,
Miguel
en if it gets
reviewed, you can still split, keeping their tag. Thanks!
Cheers,
Miguel
ps we cannot convert due to that -- I didn't
check)
Cheers,
Miguel
hanks for doing these cleanups! They are appreciated.
Cheers,
Miguel
ctually enabled the lint with e.g.
#![warn(clippy::non_send_fields_in_send_ty)]
at the top of the file, and then used `expect`, it will build fine.
Cheers,
Miguel
). I am not sure if it is worth enforcing it for
every single case, though.
It would be nice if `clippy::allow_attributes_without_reason` could be
enabled just for `allow`, or ignore it for certain lints.
Cheers,
Miguel
On Sat, Jun 28, 2025 at 6:03 AM Onur wrote:
>
> I already tried that but it didn't helped. I was able to make it work
> with manually hacking the `init/Kconfig` file.
That should not be needed -- the `/` command should tell you what you
are missing.
Cheers,
Miguel
don't need it
anymore?
For instance, please how I reasoned about it in commit 5e7c9b84ad08
("rust: sync: remove unneeded
`#[allow(clippy::non_send_fields_in_send_ty)]`").
(It may happen to be the same reason, or not.)
Thanks!
Cheers,
Miguel
else may be
missing to enable a symbol.
I hope that helps.
Cheers,
Miguel
om
FFI mappings `c_long` is always `isize` now, which is always different
from `c_int` (`i32`).
By the way, please Cc the rust-for-linux list too.
Thanks!
Cheers,
Miguel
kely.
>
> Reviewed-by: Benno Lossin
> Signed-off-by: Jesung Yang
> Link:
> https://rust-for-linux.zulipchat.com/#narrow/channel/288089/topic/x/near/520452733
Applied to `rust-next` -- thanks everyone!
Cheers,
Miguel
On Mon, Jun 23, 2025 at 1:48 PM Benno Lossin wrote:
>
> Another way would be to use a `Once`-like type (does that exist on the C
> side?) so a type that can be initialized once and then never changes.
There are `DO_ONCE{,_SLEEPABLE,_LITE}`.
Cheers,
Miguel
/kernel/net/phy.rs`? Should
we factor out the formatting?
Thanks!
Cheers,
Miguel
On Sat, Jun 21, 2025 at 3:57 PM Alexey Gladkov wrote:
>
> rust/kernel/device_id.rs | 8
Cc'ing maintainers and list.
Cheers,
Miguel
se `c_*` should be unqualified).
Cheers,
Miguel
ot really useful vs. having some docs.
But another question is: if the docs are not useful, should an item be
hidden to begin with?
(By the way, that one is `rustc`, not Clippy)
Cheers,
Miguel
ginal (!HAS_EL2 && !HAS_EL2_E2H0)
2) HAS_EL2 && HAS_EL2_E2H0
3) HAS_EL2 && !HAS_EL2_E2H0
Tests 1) and 2) returned in approx. the same amount of real time (about 12s)
although 3) doesn’t
seem to return at all.
I’ve tested it on ampere-one.
Miguel
> Changes since v1:
>
>
The following two tests arch_timer and vgic_lpi_stress pass for a guest in VHE
mode but in a nVHE mode guest they are failing for me. I’ve tested them on
Marc’s repo tag 'kvmarm-fixes-6.16-1' on an AmpereOne.
Do you have plans to add nvhe mode testing to this series?
Than
or if this is ok
> to do on apply.
Thanks! No worries, I can do that on apply.
Cheers,
Miguel
On Thu, May 29, 2025 at 3:15 PM Tamir Duberstein wrote:
>
> Include all information in the panic message rather than emit fragments
> to stderr.
Could we explain the "why" as well in the message? (i.e. not just the "what")
Thanks!
Cheers,
Miguel
kely.
>
> Reviewed-by: Benno Lossin
> Signed-off-by: Jesung Yang
> Link:
> https://rust-for-linux.zulipchat.com/#narrow/channel/288089/topic/x/near/520452733
Looks good to me, thanks! If KUnit picks this next cycle:
Acked-by: Miguel Ojeda
Otherwise, I am happy to take it too.
Cheers,
Miguel
you will see the prelude there :)
Thanks!
Cheers,
Miguel
On Tue, May 27, 2025 at 2:10 AM Miguel Ojeda
wrote:
>
> [ Used the `cfg_attr` from the TODO comment and clarified its comment
> now that the stabilization is in beta and thus quite likely stable
> in Rust 1.88.0. Simplified the `new_body` code by introducing a new
>
every `Result` in the kernel), so I suggested doing that but opt-in,
i.e. with a Kconfig option that would be in e.g. the debug menu. Then
people could typically run their debug kernels and things like KUnit
with it enabled, but production kernels without it. Then later on, if
it proves useful for other things, we could try to figure out ways to
do it without too much cost.
Cheers,
Miguel
elude is (so far) not a "real prelude" that gets injected
automatically. So I guess you mean importing the prelude instead.
(It is imported in the KUnit series anyway, so it will llikely be
there either way)
Thanks!
Cheers,
Miguel
On Tue, May 27, 2025 at 2:10 AM Miguel Ojeda
wrote:
>
> [ Split from the next commit as suggested by Tamir. - Miguel ]
>
> [ Split the `CString` simplification into a new commit. - Miguel ]
By the way, I kept the tags from David and Danilo in that new commit,
since it was r
On Fri, May 2, 2025 at 11:51 PM Miguel Ojeda wrote:
>
> Improvements that build on top of the very basic `#[test]` support merged in
> v6.15.
>
> They are fairly minimal changes, but they allow us to map `assert*!`s back to
> KUnit, plus to add support for test functions tha
soon, I did a few final minor tweaks and I am applying
it.
Cheers,
Miguel
od first issue", since that
would be a good one I think).
Thanks!
Cheers,
Miguel
t;Link:" tag
to the discussion in Zulip.)
Cheers,
Miguel
right?
I think we can wait to see if we need it, or we can also just remove
it and re-introduce later if needed.
Thanks for taking a look!
Cheers,
Miguel
Sure, the line would need to change again later, but that is fine too,
we can do a separate commit.
Cheers,
Miguel
plans on their side here. For instance, for Rust, we wanted to
eventually have a way to tag stuff as kernel vs. host etc., but that
is longer term.
Cheers,
Miguel
uilding the kernel
normally. In a way, these restricted host tests actually are an extra
hassle, in that you have to deal with yet another test environment and
special restrictions.
But which host tests are you referring to?
Thanks for reviewing!
Cheers,
Miguel
to differentiate between
code under test vs. other code failing.
> These changes don't depend on returning `Result` from the tests
> AFAICT. Can they be in a separate patch?
Not sure what you mean. The change below uses `?`, which is what
allows this to be removed.
Thanks!
Cheers,
Miguel
aps printing
it "manually" in the log, possibly in a KUnit `# ...`. David can
probably suggest the "proper" way.
Thanks!
Cheers,
Miguel
Now that `rusttest`s are not really used much, clarify the section of
the documentation that describes them.
In addition, free the section name for the KUnit-based `#[test]`s that
will be added afterwards. To do so, rename the section into `rusttest`
host tests.
Signed-off-by: Miguel Ojeda
There was no documentation yet on the KUnit-based `#[test]`s.
Thus add it now.
It includes an explanation about the `assert*!` macros being mapped to
KUnit and the support for `-> Result` introduced in these series.
Signed-off-by: Miguel Ojeda
---
Documentation/rust/testing.rst |
In general, we should aim to test as much as possible within the actual
kernel, and not in the build host.
Thus convert these `rusttest` tests into KUnit tests.
Signed-off-by: Miguel Ojeda
---
rust/kernel/str.rs | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a
!`s.
Signed-off-by: Miguel Ojeda
---
rust/kernel/str.rs | 68 --
1 file changed, 30 insertions(+), 38 deletions(-)
diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
index cf2caa2db168..8dcfb11013f2 100644
--- a/rust/kernel/str.rs
+++ b/rust/kernel/str
It is convenient to have certain things in the `kernel` prelude, and
means kernel developers will find it even easier to start writing tests.
And, anyway, nobody should need to use this identifier for anything else.
Thus add it to the prelude.
Signed-off-by: Miguel Ojeda
---
rust/kernel
747345] not ok 4 my_test_suite
Signed-off-by: Miguel Ojeda
---
rust/kernel/kunit.rs | 25 +
rust/macros/kunit.rs | 3 ++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/rust/kernel/kunit.rs b/rust/kernel/kunit.rs
index 2659895d4c5d..f43e3ed460c2 100644
---
t ok 2 my_second_test
[1.930032] # my_test_suite: pass:0 fail:2 skip:0 total:2
[1.930153] # Totals: pass:0 fail:2 skip:0 total
Link: https://github.com/rust-lang/rust/pull/140514 [1]
Signed-off-by: Miguel Ojeda
---
init/Kconfig | 3 +++
rust/Makefile | 3 ++-
rust/
documentation
tests.
I also took the chance to convert some host `#[test]`s we had to KUnit in order
to showcase the feature.
Finally, I added documentation that was lacking from the original submission.
I hope this helps.
Miguel Ojeda (7):
rust: kunit: support KUnit-mapped `assert!` macros in
On Fri, May 2, 2025 at 2:08 PM Andreas Hindborg wrote:
>
> And I don't have the same built-in linter in my mind as you have 😅
I am not sure having one is a good or a bad thing, to be honest! :)
Cheers,
Miguel
// integer. We choose u64 as sufficiently large.
`u64`
(These were all in the range-diff :)
Cheers,
Miguel
133
ok 2 rust_doctests_kernel
Cheers,
Miguel
.sh to make
> the user explicitly ask for it?
One may run KUnit without using `kunit.py`, i.e. by enabling the
Kconfigs and booting the kernel. Would that help?
Cheers,
Miguel
each patch (unless you think there are enough
changes that it should not be done anymore etc.).
For instance, in v4, this one was Reviewed-by: David, and a couple
others were Reviewed-by Boqun; and from what I can tell, they didn't
change.
Thanks!
Cheers,
Miguel
hus it does not fit
since it is 2's complement, even if later the complement would.
In fact, it is caught by the doctest when run with debug assertions enabled:
/// assert_eq!(Ok(-128), i8::from_str(b_str!("-128")));
We try to put 128 into `i8`, which of course does not work...
Cheers,
Miguel
or the `rusttest` target. - Miguel ]
Attached range diff of what I did.
I hope that helps!
Cheers,
Miguel
+@@ rust/kernel/str.rs: macro_rules! c_str {
+ }
+
+ #[cfg(test)]
+-#[expect(clippy::items_after_test_module)]
+ mod tests {
+ use super::*;
+
@@ rust/kernel/str.rs: fn fmt(&self, f: &am
chi-Kaye lifted from the original `rust` branch
> [1].
>
> Link:
> https://github.com/Rust-for-Linux/linux/tree/bc22545f38d74473cfef3e9fd65432733435b79f
> [1]
> Signed-off-by: Andreas Hindborg
Applied (1-4) to `rust-next` -- thanks everyone!
[ Pluralized section name. Hid `u
ike a good idea to me.
Cheers,
Miguel
Anyway, KUnit `#[test]`s are in -- I was not planning to merge this
now anyway, it should be reviewed a bit more.
Thanks!
Cheers,
Miguel
amir's) are independent, and in my
view they shouldn't delay something (a feature) like this series.
Cheers,
Miguel
On Thu, Mar 20, 2025 at 11:26 AM Andreas Hindborg wrote:
>
> As far as I understand, Miguel would take patch 1-5 for v6.15 and
> modules would take patch 6-7 for v6.16. At least that is my
> understanding from [1], @Petr and @Miguel please correct me if I am
> wrong.
So I off
d-to-go for 6.15, so we can start using it concurrently with
> making any additional improvements we may wish.
Applied to `rust-next` -- thanks everyone!
[ Applied Markdown in comment. - Miguel ]
[ Removed spurious (in rendered form) newline in docs. - Miguel ]
(finally! Speci
On Thu, Mar 13, 2025 at 5:30 AM Joel Fernandes wrote:
>
> Reviewed-by: Joel Fernandes
>
> If no objections, I can queue it for 6.16 but let me know if Rust maintainers
> prefer to take it.
Thanks! That would be great -- FWIW:
Acked-by: Miguel Ojeda
By the way, should `read_lo
On Thu, Mar 13, 2025 at 1:41 AM Philip Li wrote:
>
> Sorry about this, I will implement this to make it clear asap.
The bot is great -- thanks for all the resources you have put so far into it :)
Cheers,
Miguel
nfig (i.e.
`CONFIG_RUSTC_VERSION_TEXT`).
Cheers,
Miguel
On Fri, Mar 7, 2025 at 5:58 PM Benno Lossin wrote:
>
> You link to the `ptr_as_ptr` lint though, is this a typo?
I think Tamir was following the pattern of commit 3fcc23397628 ("rust:
enable `clippy::ignored_unit_patterns` lint"), which I appreciate! :)
Cheers,
Miguel
ugging features,
but also docs, KUnit, and so on.
That is why we would like to improve it and why we have it in our
upstream Rust wishlist and so on. In other words, it is not that we do
not see the issue!
I hope that clarifies.
Cheers,
Miguel
t has a hint, though that may have
disadvantages.
Cheers,
Miguel
rust/macros/module.rs, then yes, I'd say
> it should be ok to take the patches through the modules tree.
Yeah, that should be the case. Worst case, we can do the delay-a-cycle
thing, or if urgent create a small branch, etc.
Cheers,
Miguel
lback would be putting it in the Rust tree as
a sub-entry or similar.
I hope that clarifies (and thanks whatever you decide!).
https://lore.kernel.org/rust-for-linux/caniq72mpyoig2ro76k0e-sutp31fw+0403zywd6mumcgfkf...@mail.gmail.com/
Would any of those other options work for you?
Thanks!
Cheers,
Miguel
though). So
we should do one of the other approaches discussed in the previous
versions, like call into the C one.
Cheers,
Miguel
w,
because it is indeed confusing.
I hope that helps.
Cheers,
Miguel
we land this, the easier it may be...).
Cheers,
Miguel
o have "attributes" or "tags" like `#[test(host, kernel)]`.
But, again, something for later -- I would rather we finally land `#[test]`s.
Cheers,
Miguel
On Sun, Jan 5, 2025 at 2:33 PM Miguel Ojeda
wrote:
>
> Thanks for the report! I think there is nothing to be done here given
> the details above.
To clarify: v6.11.y is newer (and EOL), v6.12.y LTS is newer, and
older LTSs had the Rust toolchain pinned.
If there is something I a
-rc1).
> toolchain: rustgcc
> compiler: 'name': 'gcc', 'version': '14', 'version_full': 'gcc
> (Debian 14.2.0-8) 14.2.0'
By the way, it would be nice to mention here the Rust compiler too, if used.
Thanks for the report! I think there is nothing to be done here given
the details above.
Cheers,
Miguel
esult in the list for
a few days (and/or put it early next cycle) given the magnitude of the
changes.
Finally, it is not a blocker for 6.14 or otherwise, but we should
eventually add/explain the new features in
`Documentation/rust/testing.rst`.
Thanks again!
Cheers,
Miguel
g to say here? i.e. it is always safe to call from
both C and Rust, no? Or is there something I am missing?
> +// when KUnit is not enabled), and we're only comparing the result to
> NULL.
Does "and we're only comparing the result to NULL" need to be part of
the safety comment? i.e. comparing a pointer is safe (and `is_null()`
too).
> +let in_kunit = in_kunit_test();
> +assert!(in_kunit);
I would simplify and call directly the function.
Cheers,
Miguel
}
//
// static mut TEST_CASES: [kernel::bindings::kunit_case; 3] = [
// kernel::kunit::kunit_case(kernel::c_str!("foo"),
kunit_rust_wrapper_foo),
// kernel::kunit::kunit_case(kernel::c_str!("bar"),
kunit_rust_wrapper_bar),
// kernel::kunit::kunit_case_null()
// ];
//
// kernel::kunit_unsafe_test_suite!(kunit_test_suit_name, TEST_CASES);
// ```
...with the corresponding removals in the actual generation code
below, of course.
Cheers,
Miguel
t::kunit_case_null(),
];
And then:
test_cases: unsafe {
::core::ptr::addr_of_mut!($test_cases).cast::<::kernel::bindings::kunit_case>()
},
So no mutable references in sight.
> #![feature(unsize)]
> +#![feature(const_mut_refs)]
The list should be kept sorted.
However, we can avoid enabling the feature I think, if we avoid the
`&mut`s (please see above).
Cheers,
Miguel
ot break
anything in your case, i.e. it is just a replacement.
Thanks!
Cheers,
Miguel
Acked-bys the way they prefer, yet record your own Acked-by in a
separate category.
- Another idea that the maintainer may accept is an Acked-by with a
"# suffix" comment that clarifies the meaning in this particular case,
e.g.:
Acked-by: Neal Gompa # As primary consumer
(Fedora Asahi kernel maintainer).
Cheers,
Miguel
:
const _: () = {
static mut X: i32 = 42;
#[allow(unused_unsafe)]
static mut S: *const i32 = unsafe { core::ptr::addr_of_mut!(X) };
};
Cheers,
Miguel
ut we could mimic that behavior.
(Personally, I don't particularly enjoy exceptional/context-dependent
cases, unless it is something used everywhere, like `use`ing the
prelude that we have).
Cheers,
Miguel
we can
drop it globally.
Cheers,
Miguel
h, even when he
wasn't (and maybe still isn't) convinced.
Cheers,
Miguel
org7xutjueqssxgcbqb7dqfpul0sfj...@mail.gmail.com/
If you can confirm it is, that would be great, thanks! i.e. you will
need either to disable `CALL_PADDING` or use a newer Rust compiler
version.
By the way, I think you meant next-202409176, not next-20240917?
Cheers,
Miguel
On Fri, Aug 23, 2024 at 7:24 PM Sami Tolvanen wrote:
>
> I assume they wanted to avoid conflicts between Rust-specific
> environment variables and existing Kbuild variables. Note that
> KBUILD_MODFILE is also double quoted for the C preprocessor, which
> isn't needed for
comes from my
prototype I gave Alice.
Please see the attached diff.
Cheers,
Miguel
diff --git a/rust/kernel/jump_label.rs b/rust/kernel/jump_label.rs
index 7757e4f8e85e..ccfd20589c21 100644
--- a/rust/kernel/jump_label.rs
+++ b/rust/kernel/jump_label.rs
@@ -36,7 +36,7 @@ macro_rules! static_key_false
k if more
core/common subsystems start doing that -- linux-next could be broken
a lot of the time for the Rust side).
But, yes, I think Rust is a great opportunity to get new
co-maintainers, as well as getting new developers involved with kernel
maintenance in general, which could help with other issues too.
Cheers,
Miguel
best for a long time to get the
best we can for the kernel -- just 2 days ago we told the Rust project
in one of our meetings that it would be nice to see that particular
"project goal" from that document realized (among others).
Cheers,
Miguel
hing we could do to help here? I think Alice and others
would be happy to explain how it works and/or help maintain it in the
future if you prefer.
Cheers,
Miguel
1 - 100 of 1052 matches
Mail list logo
