On Wed, May 7, 2025 at 1:23 PM Benno Lossin wrote:
>
> > +unsafe extern "C" fn set_param(
> > +val: *const kernel::ffi::c_char,
> > +param: *const crate::bindings::kernel_param,
> > +) -> core::ffi::c_int
New instance of `core::ffi::` (and both these `c_*` should be unqualified).
Cheers,
On Wed, Jun 11, 2025 at 2:24 PM Andreas Hindborg wrote:
>
> So either we need to `#[allow(missing_docs)]` or just add the line back. What
> do you prefer?
Do you mean if you remove the `concat!` too, right?
It would need to be `expect`, but I think even an
`expect(missing_docs)` is not really u
On Thu, May 29, 2025 at 4:38 PM Tamir Duberstein wrote:
>
> Sure, that would be:
>
> Include all information in the panic message rather than emit fragments
> to stderr to avoid possible interleaving with other output.
>
> Let me know if I should send another spin for this, or if this is ok
> to d
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
On Wed, May 28, 2025 at 5:55 PM Jesung Yang wrote:
>
> So in sum, I believe it's reasonable to keep the diff unchanged... but
> I'm happy to adjust if you'd prefer a different approach.
I see this is based on rust-next -- if you rebase the patch on top of
the latest one, you will see the prelude
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
>
On Tue, May 6, 2025 at 8:33 AM David Gow wrote:
>
> FWIW, having out-of-memory situations trigger a test failure is
> consistent with what other KUnit tests (written in C) do.
>
> There's both advantages and disadvantages to this: on the one hand,
> it's prone to false positives (as you mention),
On Tue, May 27, 2025 at 2:06 PM Benno Lossin wrote:
>
> We don't need to explicitly import it, as `c_void` is present in the
> prelude since 3d5bef5d47c3 ("rust: add C FFI types to the prelude").
Hmm... But the prelude isn't there yet in this patch, no? i.e. our
prelude is (so far) not a "real pr
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
On Mon, May 5, 2025 at 8:02 AM David Gow wrote:
>
> Nice! While I do think there may still be some cases where we might
> want to use KUnit-specific macros in the future (particularly if we
> have more complex, multithreaded test contexts), this is definitely
> better for most cases.
>
> I also ma
On Sun, May 4, 2025 at 7:42 PM Tamir Duberstein wrote:
>
> How come this vanished?
It doesn't lint anymore -- the lint only appears to be intended to
work with the standard `assert_eq!` macro (and related ones), if I am
reading its source code correctly.
I created an issue upstream and linked it
On Mon, May 26, 2025 at 6:26 PM Jesung Yang wrote:
>
> Since `kernel::ffi::c_void` is a transparent wrapper around
> `core::ffi::c_void`, both are functionally equivalent. However, using
Hmm... It is not a transparent wrapper, but a reexport, right? (it is
not even a type alias, like the others i
On Mon, May 5, 2025 at 6:57 PM Danilo Krummrich wrote:
>
> With that, do we still expose `alloc` primitives to userspace tests?
I considered removing a bunch of stuff (even the build support for
non-`macros` `rusttest`, to be honest) -- you are referring to the
`any(test, testlib)` bits, right?
On Sun, May 4, 2025 at 8:23 PM Tamir Duberstein wrote:
>
> I see. Up to you, obviously, but ISTM that this degree of freedom is
> unnecessary, but perhaps there's a benefit I'm underappreciating?
Well, having this allows one to write code like the rest of the kernel
code, instead of, say, `.unwra
On Sun, May 4, 2025 at 8:39 PM Tamir Duberstein wrote:
>
> One example is
> https://github.com/torvalds/linux/blob/59c9ab3e8cc7f56cd65608f6e938b5ae96eb9cd2/tools/testing/radix-tree/xarray.c.
>
> It might be that these are necessary because the xarray tests don't
> use kunit, and so are pretty inc
On Sun, May 4, 2025 at 7:31 PM Tamir Duberstein wrote:
>
> Is that true? The build host is often easier to work with. There's a
> number of host tests on the C side that exist precisely for this
> reason.
Even for tests that could run in the host (pure functions), if you
test in the host, then yo
On Sun, May 4, 2025 at 7:30 PM Tamir Duberstein wrote:
>
> Alice pointed this out in another thread but: one of the downsides of
> returning Result is that in the event of failure the line number where
> the error occurred is no longer contained in the test output. I'm 👎
> on this change for that
On Sun, May 4, 2025 at 7:34 PM Tamir Duberstein wrote:
>
> Why not restrict this to Result<(), E>?
I guess it is an option -- not sure if there may be a use case.
> Is it possible to include the error in the output?
I thought about giving some more context somehow and perhaps printing
it "manua
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
On Thu, May 1, 2025 at 9:55 AM Andreas Hindborg wrote:
>
> +pub mod parse_int {
> +
> +use crate::prelude::*;
Spurious newline.
> +use crate::str::BStr;
> +use core::ops::Deref;
> +/// # Examples
> +/// ```
Missing newline.
> +// integer. We choose u64
On Fri, Apr 18, 2025 at 8:04 PM Paul E. McKenney wrote:
>
> Suppose we fired up a guest OS and captured the console output. Is there
> a way to make that guest OS shut down automatically at the end of the
> test and to extract the test results?
Ah, sorry, I thought you were already doing somethi
On Fri, Apr 18, 2025 at 6:10 PM Joel Fernandes wrote:
>
> a rust_doctests_kernel kunit run. Note that kunit wants a clean source
> tree, so this runs "make mrproper", which might come as a surprise to
> some users. Should there be a --mrproper parameter to torture.sh to make
> the user explicitl
On Thu, Mar 20, 2025 at 3:08 AM Antonio Hickey
wrote:
>
> Replacing all occurrences of `addr_of!(place)` with
> `&raw const place`.
>
> This will allow us to reduce macro complexity, and improve consistency
> with existing reference syntax as `&raw const` is similar to `&` making
> it fit more nat
On Thu, Feb 27, 2025 at 3:39 PM Andreas Hindborg wrote:
>
> +// SAFETY: We checked that `val` will fit in `Self`
> above.
> +let val: Self = unsafe {
> val.try_into().unwrap_unchecked() };
This is wrong -- `val` can be the maximum, and thus it does not fi
On Fri, Mar 21, 2025 at 10:18 AM Andreas Hindborg wrote:
>
> Add the trait `ParseInt` for parsing string representations of integers
> where the string representations are optionally prefixed by a radix
> specifier. Implement the trait for the primitive integer types.
>
> Tested-by: Daniel Almeida
On Thu, Feb 27, 2025 at 3:39 PM Andreas Hindborg wrote:
>
> Extend the `module!` macro with support module parameters. Also add some
> string
> to integer parsing functions and updates `BStr` with a method to strip a
> string
> prefix.
>
> Based on code by Adam Bratschi-Kaye lifted from the orig
On Fri, Mar 21, 2025 at 6:06 PM Boqun Feng wrote:
>
> I agree this whole series should wait a bit, but do we want to merge
> patch #1 as early as possible (maybe right after v6.15-rc1), so that new
> code can switch to &raw since that's the direction anyway?
Sounds like a good idea to me.
Cheers
On Tue, Mar 18, 2025 at 9:02 AM David Gow wrote:
>
> In general, I think changes such as those in this series are going to
> get progressively more prone to conflicts as Rust is adopted by other
> subsystems, as the 'rust' tree won't be the only one carrying changes
> which could be affected. Mayb
On Tue, Mar 18, 2025 at 9:14 AM David Gow wrote:
>
> The only reason for delay I can think of is all of the patches which
> adjust clippy warnings, etc., for things like addr_of_mut!() (and
> possibly some of the casting). I'm unlikely to have time to re-send
> everything out before the merge wind
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 offered that as an optio
On Fri, Mar 7, 2025 at 10:01 AM David Gow wrote:
>
> This is v8 of the Rust/KUnit integration patch. I think all of the
> suggestions have at least been responded to (even if there are a few I'm
> leaving as either future projects or matters of taste). Hopefully this
> is good-to-go for 6.15, so w
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
On Tue, Mar 11, 2025 at 9:44 PM Tamir Duberstein wrote:
>
> By the way, it would be great if the email also included the rustc version
> used.
Yeah, I think I may have mentioned it at some point... For the moment,
one can look for it manually in the linked config (i.e.
`CONFIG_RUSTC_VERSION_TEXT
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
On Fri, Feb 28, 2025 at 6:29 AM Alistair Popple wrote:
>
> I'm not sure I agree it works perfectly fine. Developer ergonomics are
> an important aspect of any build environment, and I'd argue the ergonomic
> limitation for (2) means it is at least somewhat broken and needs fixing.
>
> Anyway thank
On Thu, Feb 27, 2025 at 1:26 AM Alistair Popple wrote:
>
> I've asked a few times, but are there any plans/ideas on how to improve the
> situation? I'm kind of suprised we're building things on top of a fairly
> broken
> feature without an idea of how we might make that feature work. I'd love to
On Thu, Feb 27, 2025 at 3:55 PM Petr Pavlu wrote:
>
> From what I can see in this series, the bindings required adding
> a number of generic functions to the Rust support code and also most
> discussion revolved around that. I'm worried this might be the case also
> for foreseeable future updates,
On Tue, Feb 25, 2025 at 11:22 AM Petr Pavlu wrote:
>
> I'd say the easiest is for the entire series to go through the Rust
> tree. I'd also propose that any updates go primarily through that tree
> as well.
>
> Makes sense, I think it is useful for all changes to this code to be
> looked at by bot
On Mon, Feb 24, 2025 at 11:30 PM Janne Grunau wrote:
>
> The errors go away after exchanging i128 with i64 (while breaking the
> parsing for large values).
I don't think we can use 128-bit integers unconditionally for all
architectures (we could eventually get it to work for some though). So
we s
Hi Alistair,
On Fri, Feb 21, 2025 at 2:20 AM Alistair Popple wrote:
>
> Is this a known issue or limitation? Or is this a bug/rough edge that still
> needs fixing? Or alternatively am I just doing something wrong? Would
> appreciate
> any insights as figuring out what I'd done wrong here was a b
On Fri, Feb 14, 2025 at 8:41 AM David Gow wrote:
>
> After much delay, v6 of the KUnit/Rust integration patchset is here.
> This change incorporates most of Miguels suggestions from v5 (save for
> some of the copyright headers I wasn't comfortable unilaterally
> changing). This means the documenta
On Fri, Feb 14, 2025 at 3:41 PM Tamir Duberstein wrote:
>
> This is a really helpful comment. It got me wondering: can we have
> host-side unit tests for our proc macros? Code is better than
> comments, of course.
That makes sense (in fact, e.g. Benno wanted them for pinned-init),
but I will defe
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
On Sun, Jan 5, 2025 at 9:42 AM Naresh Kamboju wrote:
>
> The following kselftest rust builds failed on sashal/linus-next.git
> due to following build warnings / errors.
>
> Good: 829d8581c398a96deea1d6bc78578950347dcbec
> Bad: b2d472701a703596889c3fd067fd8929aeffc4be
These seem unrelated, old b
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> v5 here is a small set of fixes and a rebase of the previous versions.
> If there are no major issues, I'd like to land this soon so it can be
> used and tested ready for 6.14.
Thanks as usual David for keeping this one alive over time.
I was
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> +/// In some cases, you need to call test-only code from outside the test
> case, for example, to
> +/// create a function mock. This function can be invoked to know whether we
> are currently running a
> +/// KUnit test or not.
The documenta
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> +#[allow(unused_unsafe)]
Should this be in the first patch?
> -unsafe { core::ptr::addr_of_mut!(KUNIT_TEST_SUITE) };
> +unsafe {
> +core::ptr::addr_of_mut!(KUNIT_TEST_SUITE)
> +
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> +/// The test case should have the signature
> +/// `unsafe extern "C" fn test_case(test: *mut crate::bindings::kunit)`.
I guess this is here so that people can copy-paste it (i.e. users)?
However, given it is private (i.e. users are not expect
On Mon, Dec 16, 2024 at 5:31 PM Danilo Krummrich wrote:
>
> Thanks! If nothing else comes up, I'll send you a v7 end of this week
> addressing
> the two minor things I just replied to (remove wrong return statement in
> iounmap() helper, `pci::DeviceId` naming and `Deref` impl).
If you are going
On Mon, Nov 25, 2024 at 2:29 PM Neal Gompa wrote:
>
> As my Acked-by was removed, I'm sorry to say that there is no point
> for me to provide feedback since it is unwanted.
>
> I hope it lands soon, but I also hope the people here who decided that
> a person's efforts aren't worth recording becaus
On Sat, Nov 9, 2024 at 9:18 AM David Gow wrote:
>
> Is there somewhere else we can put the attribute to support this
> without having to either disable the warning, or use the experimental
> feature globally?
Yeah, on the item, e.g. https://godbolt.org/z/oo8osadn4:
const _: () = {
st
On Sat, Nov 2, 2024 at 1:08 AM Boqun Feng wrote:
>
> Hmm.. so I think clippy won't warn for a normal Rust #[test] function:
>
> https://github.com/rust-lang/rust-clippy/pull/7811
That is a very good point. It is a bit surprising that those details
are not documented, but we could mimic th
On Fri, Nov 1, 2024 at 10:38 PM Boqun Feng wrote:
>
> but this lint doesn't make sense to me, I would say we just drop this
> lint?
I am not sure if it is intended to fire there (i.e. to resolve
constants), but seems OK since it is not something one would want
normally to write except in exceptio
On Fri, Nov 1, 2024 at 7:03 AM Boqun Feng wrote:
>
> This time, I try implementing a generic atomic type `Atomic`, since
> Benno and Gary suggested last time, and also Rust standard library is
> also going to that direction [1].
I would like to thank Boqun for trying out this approach, even when
Hi Naresh,
On Mon, Sep 16, 2024 at 9:17 PM Naresh Kamboju
wrote:
>
> The x86 rust gcc builds failed on the Linux next-20240917 due to following
> build
> warnings / errors with rustgcc for selftests rust builds.
>
> First seen on next-20240917
> Good: next-20240913
> BAD: next-20240917
>
>
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 Rust. Miguel, do you remem
On Wed, Aug 21, 2024 at 7:08 PM Boqun Feng wrote:
>
> Have you try this with "make O="? I hit the following issue, but I
> am rebasing on rust-dev, so I might miss something:
>
> error: couldn't read ../rust/kernel/arch_static_branch_asm.rs: No
> such file or directory (os error 2)
>
On Mon, Jul 8, 2024 at 11:42 PM Luis Chamberlain wrote:
>
> The rationale here is that a rust binding means commitment then also
> from fresh blood to help co-maintain review C / Rust for exising code
> when there is will / desire to collaborate from an existing C maintainer.
>
> I realize this ma
On Fri, Jun 7, 2024 at 12:52 PM Peter Zijlstra wrote:
>
> I'm sorry, but 30+ years of reading ! as NOT (or factorial) isn't going
> to go away. So I'm reading your macros do NOT rule.
It makes it clear what is macro call or not. They could have gone for
UPPERCASE names (for instance), yes. On the
On Thu, Jun 6, 2024 at 7:19 PM Peter Zijlstra wrote:
>
> This is absolutely unreadable gibberish -- how am I supposed to keep
> this in sync with the rest of the static_call infrastructure?
Yeah, they are macros, which look different from "normal" Rust code.
Is there something we could do to hel
Hi Nick,
On Mon, Apr 19, 2021 at 10:36 PM Nick Desaulniers
wrote:
>
> This is a much different process than drafts thrown over the wall.
> What hope do any kernel contributors have to participate in the ISO
> WGs, other than hoping their contributions to a draft foresee/address
> any concerns mem
On Mon, Apr 19, 2021 at 10:18 PM Matthew Wilcox wrote:
>
> Yes, I agree, we need a better story for name mangling.
> My proposal is that we store a pretty name which matches the source
> (eg rust_binder::range_alloc) and a sha1 of the mangled symbol
> (40 bytes of uninteresting hex). Symbol resol
Hi David,
On Mon, Apr 19, 2021 at 10:01 PM David Sterba wrote:
>
> for simple functions it's barely parseable but the following is hardly
> readable
>
> translates to
>
>core[8787f43e282added]::fmt::Debug>::fmt
Some details can be omitted without much problem, e.g. try the `-i`
option of `c+
On Sat, Apr 17, 2021 at 6:24 AM Willy Tarreau wrote:
>
> My concern was to know what field to look at to reliably detect an error
> from the C side after a sequence doing C -> Rust -> C when the inner C
> code uses NULL to mark an error and the upper C code uses NULL as a valid
> value and needs t
On Sat, Apr 17, 2021 at 4:21 PM Willy Tarreau wrote:
>
> Well, I can't express how much I hate abstractions because I constantly
> need to know what it's doing under the hood, and I spend my time reading
> the output asm code because I always want to confirm my assumptions about
> the compiler not
On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
>
> But my point remains that the point of extreme care is at the interface
> with the rest of the kernel because there is a change of semantics
> there.
>
> Sure but as I said most often (due to API or ABI inheritance), both
> are already excl
On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau wrote:
>
> No, two:
> - ok in %rax (seems like it's "!ok" technically speaking since it
> returns 1 on !ok and 0 on ok)
> - foo_or_err in %rdx
Yes, but that is the implementation -- conceptually you only have one
or the other, and Rust won't
On Fri, Apr 16, 2021 at 10:22 PM Willy Tarreau wrote:
>
> So it simply does the equivalent of:
>
> struct result {
> int status;
> int error;
> };
Not exactly, it is more like a tagged union, as Connor mentioned.
However, and this is the critical bit: it is a compile-time error to
On Sun, Apr 11, 2021 at 11:27 PM Michal Suchánek wrote:
>
> Yes, I do have the rust support.
I applied your patch in rust-next and it is in the latest linux-next,
let me know if that helped.
Masahiro, if you want to apply it on your side, just let me know!
Cheers,
Miguel
On Fri, Apr 16, 2021 at 8:10 PM Al Viro wrote:
>
> How well would ? operator fit that pattern? _If_ it's just a syntax sugar
> along the lines of "if argument matches Err(_), return Err(_)", the types
> shouldn't be an issue, but that might need some fun with releasing resources,
> etc. If it's
On Fri, Apr 16, 2021 at 7:05 PM Linus Torvalds
wrote:
>
> Typical Rust error handling should match the regular kernel
> IS_ERR/ERR_PTR/PTR_ERR model fairly well, although the syntax is
> fairly different (and it's not limited to pointers).
Yeah, exactly. We already have a `KernelResult` type whic
On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra wrote:
>
> So if I read all this right, rust compiles to .o and, like any other .o
> file is then fed into objtool (for x86_64). Did you have any problems
> with objtool? Does it generate correct ORC unwind information?
I opened an issue a while ago
On Fri, Apr 16, 2021 at 6:14 PM Willy Tarreau wrote:
>
> I'm really afraid by languages which force developers to do this or that.
> Many bugs in C come from casts because developers know their use case
> better than the compiler's developers, and result in lack of warnings
> when the code evolves
On Fri, Apr 16, 2021 at 5:43 PM Peter Zijlstra wrote:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2659.htm
>
> That's just not making any damn sense what so ever. That seems to be
> about sprinkling abort() all over the place, which is just total
> rubbish.
No, it is not about that. It i
On Fri, Apr 16, 2021 at 4:19 PM Peter Zijlstra wrote:
>
> Does this also not prohibit constructs where modification must be done
> while holding two locks, but reading can be done while holding either
> lock?
Yeah, this came up in some discussions we had. There are some locking
patterns that we n
On Fri, Apr 16, 2021 at 1:24 PM Peter Zijlstra wrote:
>
> IMO RAII is over-valued, but just in case you care, the below seems to
> work just fine. No fancy new language needed, works today. Similarly you
> can create refcount_t guards, or with a little more work full blown
> smart_ptr crud.
Pleas
Hi Stephen,
On Fri, Apr 16, 2021 at 9:58 AM Stephen Rothwell wrote:
>
> from the char-misc tree and commit:
>
> 1fed5dee5fbb ("Android: Binder IPC in Rust (WIP)")
>
> from the rust tree.
If you prefer, I can take out the binder bits from rust-next since
they will be submitted separately anyhow
On Thu, Apr 15, 2021 at 8:03 PM Nick Desaulniers
wrote:
>
> Until then, I don't see why we need to permit developers to express
> such flexibility for just the Rust code, or have it differ from the
> intent of the C code. Does it make sense to set RUST_OPT_LEVEL_3 and
> CC_OPTIMIZE_FOR_SIZE? I dou
On Thu, Apr 15, 2021 at 9:10 AM Greg Kroah-Hartman
wrote:
>
> Let's see what happens here, this patchset is a great start that
> provides the core "here's how to build rust in the kernel build system",
> which was a non-trivial engineering effort. Hats off to them that "all"
> I had to do was suc
On Thu, Apr 15, 2021 at 3:38 AM Kees Cook wrote:
>
> Before anything else: yay! I'm really glad to see this RFC officially
> hit LKML. :)
Thanks! :)
> When originally learning Rust I was disappointed to see that (by default)
> Rust similarly ignores the overflow problem, but I'm glad to see the
Hi Nathan,
Sorry, with all the other things I ended up not replying to you before
going to sleep.
On Wed, Apr 14, 2021 at 8:59 PM Nathan Chancellor wrote:
>
> Shuffling this around will cause this issue (I never saw you CC'd on the
> thread).
>
> https://lore.kernel.org/r/f6218ac526a04fa4d4406f9
On Thu, Apr 15, 2021 at 2:23 AM Nick Desaulniers
wrote:
>
> Looks like Wedson's writeup is now live. Nice job Wedson!
> https://security.googleblog.com/2021/04/rust-in-linux-kernel.html
+1 It is very nicely written and explains the semaphore samples
(included in the RFC) he wrote, with nice table
On Thu, Apr 15, 2021 at 1:47 AM Nick Desaulniers
wrote:
>
> I'm ok with this approach, but I'm curious:
> If the user made a copy of the CLANG_FLAGS variable and modified its
> copy, would TENTATIVE_CLANG_FLAGS even be necessary? IIUC,
> TENTATIVE_CLANG_FLAGS is used to filter out certain flags be
On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
wrote:
>
> Rather than check the origin (yikes, are we intentionally avoiding env
> vars?), can this simply be
> ifneq ($(CLIPPY),)
> KBUILD_CLIPPY := $(CLIPPY)
> endif
>
> Then you can specify whatever value you want, support command line or
> en
Hi Nick,
Thanks a lot for looking into this!
On Thu, Apr 15, 2021 at 12:18 AM Nick Desaulniers
wrote:
>
> Was this TODO meant to be removed, or is it still pending? If pending,
> on what? Being able to link back on itself if/once merged?
Still pending -- the plan is to upload the docs to kernel
On Wed, Apr 14, 2021 at 11:55 PM Nick Desaulniers
wrote:
>
> Assuming this will at least be part of Wedson's core responsibilities,
> shouldn't this be "Supported." Per Maintainers:
Yeah, we were waiting until a couple other announcements to change it
-- but it will most likely be "Supported" by
On Wed, Apr 14, 2021 at 10:10 PM Matthew Wilcox wrote:
>
> On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> > - Manish Goregaokar implemented the fallible `Box`, `Arc`, and `Rc`
> > allocator APIs in Rust's `alloc` standard library for us.
>
> There's a philosophical point
On Wed, Apr 14, 2021 at 9:45 PM Linus Torvalds
wrote:
>
> With the main point of Rust being safety, there is no way I will ever
> accept "panic dynamically" (whether due to out-of-memory or due to
> anything else - I also reacted to the "floating point use causes
> dynamic panics") as a feature in
On Wed, Apr 14, 2021 at 9:45 PM Matthew Wilcox wrote:
>
> How about doing something a bit more utf-8-like?
>
> len = data[0];
> if (len == 0)
> error
> else if (len < 128)
> return len;
> else if (len < 192)
> return 1
1 - 100 of 796 matches
Mail list logo
