From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: David Gow <davidgow@google.com>
Cc: Miguel Ojeda <ojeda@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jarkko Sakkinen <jarkko@kernel.org>,
KUnit Development <kunit-dev@googlegroups.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
live-patching@vger.kernel.org
Subject: Re: [PATCH v6 00/23] Rust support
Date: Tue, 10 May 2022 13:36:11 +0200 [thread overview]
Message-ID: <CANiq72mcvKDW6qO=1PzYR_U0tAwVLyCWFZjFVLL81znWDSYq7A@mail.gmail.com> (raw)
In-Reply-To: <CABVgOSkrvfvA7Ay4GC5wg64S1gibvm5_U5VGBog3sw4_UFo8Cg@mail.gmail.com>
Hi David,
On Tue, May 10, 2022 at 6:45 AM David Gow <davidgow@google.com> wrote:
>
> I've just sent out a pull request to get this working under UML as
> well, which would simplify running these further:
> https://github.com/Rust-for-Linux/linux/pull/766
Thanks a lot!
> Yeah, these are all fair points: particularly for small doctests.
>
> Maybe having an optional name, which more significant tests could use
> to override the file:line names? That could be useful for a few of the
> larger, more often referenced tests.
Sounds reasonable. I can add support for that.
> Ugh: it's a bit ugly either way. I suspect that file:line is still
> probably better, if only because we need some way of looking up the
> test in the code if it fails. I'd hate for people to be randomly
> hashing bits of just to find out what test is failing.
One redeeming quality is that the assertion prints the line/file
number in the generated file, so it would still be possible to check
where it came from:
[13:13:43] # rust_kernel_doctest_str_rs_somehash: ASSERTION FAILED
at rust/doctests_kernel_generated.rs:2209
[13:13:43] Expected 2 > 3 to be true, but is false
[13:13:43] not ok 43 - rust_kernel_doctest_str_rs_somehash
[13:13:43] [FAILED] rust_kernel_doctest_str_rs_somehash
Another alternative is to keep the file:line information around
without embedding it into the test name, e.g. in a TAP comment or a
mapping file (which `kunit.py` could read).
But, yeah, before doing hashes or things like that, I would just go
for simplicity and keep things as they are unless some use case really
needs doctests to be stable.
> Oops: I missed that (one of the issues with testing this on a
> different machine which had a rust toolchain). Looks good to me.
>
> Ah: I didn't realise the plan was always to have crate-specific
> suites, and possibly to split things up.
>
> The KTAP output specification does actually support arbitrary nesting
> (though KUnit itself doesn't at the moment), which would potentially
> be an option if (e.g.) providing the complete module nesting made
> sense. I'm not convinced that'd make things easier to read, though.
That is useful to know in case we need it, thanks!
Cheers,
Miguel
WARNING: multiple messages have this Message-ID (diff)
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: David Gow <davidgow@google.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Jarkko Sakkinen <jarkko@kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
Miguel Ojeda <ojeda@kernel.org>,
live-patching@vger.kernel.org,
linux-riscv <linux-riscv@lists.infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
KUnit Development <kunit-dev@googlegroups.com>
Subject: Re: [PATCH v6 00/23] Rust support
Date: Tue, 10 May 2022 13:36:11 +0200 [thread overview]
Message-ID: <CANiq72mcvKDW6qO=1PzYR_U0tAwVLyCWFZjFVLL81znWDSYq7A@mail.gmail.com> (raw)
In-Reply-To: <CABVgOSkrvfvA7Ay4GC5wg64S1gibvm5_U5VGBog3sw4_UFo8Cg@mail.gmail.com>
Hi David,
On Tue, May 10, 2022 at 6:45 AM David Gow <davidgow@google.com> wrote:
>
> I've just sent out a pull request to get this working under UML as
> well, which would simplify running these further:
> https://github.com/Rust-for-Linux/linux/pull/766
Thanks a lot!
> Yeah, these are all fair points: particularly for small doctests.
>
> Maybe having an optional name, which more significant tests could use
> to override the file:line names? That could be useful for a few of the
> larger, more often referenced tests.
Sounds reasonable. I can add support for that.
> Ugh: it's a bit ugly either way. I suspect that file:line is still
> probably better, if only because we need some way of looking up the
> test in the code if it fails. I'd hate for people to be randomly
> hashing bits of just to find out what test is failing.
One redeeming quality is that the assertion prints the line/file
number in the generated file, so it would still be possible to check
where it came from:
[13:13:43] # rust_kernel_doctest_str_rs_somehash: ASSERTION FAILED
at rust/doctests_kernel_generated.rs:2209
[13:13:43] Expected 2 > 3 to be true, but is false
[13:13:43] not ok 43 - rust_kernel_doctest_str_rs_somehash
[13:13:43] [FAILED] rust_kernel_doctest_str_rs_somehash
Another alternative is to keep the file:line information around
without embedding it into the test name, e.g. in a TAP comment or a
mapping file (which `kunit.py` could read).
But, yeah, before doing hashes or things like that, I would just go
for simplicity and keep things as they are unless some use case really
needs doctests to be stable.
> Oops: I missed that (one of the issues with testing this on a
> different machine which had a rust toolchain). Looks good to me.
>
> Ah: I didn't realise the plan was always to have crate-specific
> suites, and possibly to split things up.
>
> The KTAP output specification does actually support arbitrary nesting
> (though KUnit itself doesn't at the moment), which would potentially
> be an option if (e.g.) providing the complete module nesting made
> sense. I'm not convinced that'd make things easier to read, though.
That is useful to know in case we need it, thanks!
Cheers,
Miguel
WARNING: multiple messages have this Message-ID (diff)
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: David Gow <davidgow@google.com>
Cc: Miguel Ojeda <ojeda@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jarkko Sakkinen <jarkko@kernel.org>,
KUnit Development <kunit-dev@googlegroups.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
live-patching@vger.kernel.org
Subject: Re: [PATCH v6 00/23] Rust support
Date: Tue, 10 May 2022 13:36:11 +0200 [thread overview]
Message-ID: <CANiq72mcvKDW6qO=1PzYR_U0tAwVLyCWFZjFVLL81znWDSYq7A@mail.gmail.com> (raw)
In-Reply-To: <CABVgOSkrvfvA7Ay4GC5wg64S1gibvm5_U5VGBog3sw4_UFo8Cg@mail.gmail.com>
Hi David,
On Tue, May 10, 2022 at 6:45 AM David Gow <davidgow@google.com> wrote:
>
> I've just sent out a pull request to get this working under UML as
> well, which would simplify running these further:
> https://github.com/Rust-for-Linux/linux/pull/766
Thanks a lot!
> Yeah, these are all fair points: particularly for small doctests.
>
> Maybe having an optional name, which more significant tests could use
> to override the file:line names? That could be useful for a few of the
> larger, more often referenced tests.
Sounds reasonable. I can add support for that.
> Ugh: it's a bit ugly either way. I suspect that file:line is still
> probably better, if only because we need some way of looking up the
> test in the code if it fails. I'd hate for people to be randomly
> hashing bits of just to find out what test is failing.
One redeeming quality is that the assertion prints the line/file
number in the generated file, so it would still be possible to check
where it came from:
[13:13:43] # rust_kernel_doctest_str_rs_somehash: ASSERTION FAILED
at rust/doctests_kernel_generated.rs:2209
[13:13:43] Expected 2 > 3 to be true, but is false
[13:13:43] not ok 43 - rust_kernel_doctest_str_rs_somehash
[13:13:43] [FAILED] rust_kernel_doctest_str_rs_somehash
Another alternative is to keep the file:line information around
without embedding it into the test name, e.g. in a TAP comment or a
mapping file (which `kunit.py` could read).
But, yeah, before doing hashes or things like that, I would just go
for simplicity and keep things as they are unless some use case really
needs doctests to be stable.
> Oops: I missed that (one of the issues with testing this on a
> different machine which had a rust toolchain). Looks good to me.
>
> Ah: I didn't realise the plan was always to have crate-specific
> suites, and possibly to split things up.
>
> The KTAP output specification does actually support arbitrary nesting
> (though KUnit itself doesn't at the moment), which would potentially
> be an option if (e.g.) providing the complete module nesting made
> sense. I'm not convinced that'd make things easier to read, though.
That is useful to know in case we need it, thanks!
Cheers,
Miguel
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: David Gow <davidgow@google.com>
Cc: Miguel Ojeda <ojeda@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jarkko Sakkinen <jarkko@kernel.org>,
KUnit Development <kunit-dev@googlegroups.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
live-patching@vger.kernel.org
Subject: Re: [PATCH v6 00/23] Rust support
Date: Tue, 10 May 2022 13:36:11 +0200 [thread overview]
Message-ID: <CANiq72mcvKDW6qO=1PzYR_U0tAwVLyCWFZjFVLL81znWDSYq7A@mail.gmail.com> (raw)
In-Reply-To: <CABVgOSkrvfvA7Ay4GC5wg64S1gibvm5_U5VGBog3sw4_UFo8Cg@mail.gmail.com>
Hi David,
On Tue, May 10, 2022 at 6:45 AM David Gow <davidgow@google.com> wrote:
>
> I've just sent out a pull request to get this working under UML as
> well, which would simplify running these further:
> https://github.com/Rust-for-Linux/linux/pull/766
Thanks a lot!
> Yeah, these are all fair points: particularly for small doctests.
>
> Maybe having an optional name, which more significant tests could use
> to override the file:line names? That could be useful for a few of the
> larger, more often referenced tests.
Sounds reasonable. I can add support for that.
> Ugh: it's a bit ugly either way. I suspect that file:line is still
> probably better, if only because we need some way of looking up the
> test in the code if it fails. I'd hate for people to be randomly
> hashing bits of just to find out what test is failing.
One redeeming quality is that the assertion prints the line/file
number in the generated file, so it would still be possible to check
where it came from:
[13:13:43] # rust_kernel_doctest_str_rs_somehash: ASSERTION FAILED
at rust/doctests_kernel_generated.rs:2209
[13:13:43] Expected 2 > 3 to be true, but is false
[13:13:43] not ok 43 - rust_kernel_doctest_str_rs_somehash
[13:13:43] [FAILED] rust_kernel_doctest_str_rs_somehash
Another alternative is to keep the file:line information around
without embedding it into the test name, e.g. in a TAP comment or a
mapping file (which `kunit.py` could read).
But, yeah, before doing hashes or things like that, I would just go
for simplicity and keep things as they are unless some use case really
needs doctests to be stable.
> Oops: I missed that (one of the issues with testing this on a
> different machine which had a rust toolchain). Looks good to me.
>
> Ah: I didn't realise the plan was always to have crate-specific
> suites, and possibly to split things up.
>
> The KTAP output specification does actually support arbitrary nesting
> (though KUnit itself doesn't at the moment), which would potentially
> be an option if (e.g.) providing the complete module nesting made
> sense. I'm not convinced that'd make things easier to read, though.
That is useful to know in case we need it, thanks!
Cheers,
Miguel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-10 11:36 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 5:23 [PATCH v6 00/23] Rust support Miguel Ojeda
2022-05-07 5:23 ` Miguel Ojeda
2022-05-07 5:23 ` Miguel Ojeda
2022-05-07 5:23 ` Miguel Ojeda
2022-05-07 5:23 ` [PATCH v6 01/23] kallsyms: avoid hardcoding the buffer size Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 02/23] kallsyms: support "big" kernel symbols Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 03/23] kallsyms: increase maximum kernel symbol length to 512 Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 04/23] kunit: take `kunit_assert` as `const` Miguel Ojeda
2022-05-12 19:01 ` Brendan Higgins
2022-05-07 5:24 ` [PATCH v6 05/23] rust: add C helpers Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 06/23] rust: add `compiler_builtins` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 07/23] rust: import upstream `alloc` crate Miguel Ojeda
2022-05-07 9:23 ` Kees Cook
2022-05-07 9:33 ` Miguel Ojeda
2022-05-07 17:06 ` Kees Cook
2022-05-07 17:30 ` Linus Torvalds
2022-05-07 19:34 ` Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 08/23] rust: adapt `alloc` crate to the kernel Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 09/23] rust: add `build_error` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 10/23] rust: add `macros` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 11/23] rust: add `kernel` crate's `sync` module Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 12/23] rust: add `kernel` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 13/23] rust: export generated symbols Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 14/23] vsprintf: add new `%pA` format specifier Miguel Ojeda
2022-05-07 8:19 ` Kees Cook
2022-05-07 9:35 ` Miguel Ojeda
2022-05-10 8:38 ` Petr Mladek
2022-05-10 10:45 ` Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 15/23] scripts: add `rustdoc_test_{builder,gen}.py` scripts Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 16/23] scripts: add `generate_rust_analyzer.py` scripts Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 17/23] scripts: decode_stacktrace: demangle Rust symbols Miguel Ojeda
2022-05-07 8:32 ` Kees Cook
2022-05-07 10:21 ` Miguel Ojeda
2022-05-07 17:09 ` Kees Cook
2022-05-07 5:24 ` [PATCH v6 18/23] docs: add Rust documentation Miguel Ojeda
2022-05-07 8:15 ` Kees Cook
2022-05-07 8:45 ` Miguel Ojeda
2022-05-09 4:02 ` Akira Yokosawa
2022-05-09 10:41 ` Miguel Ojeda
2022-05-09 14:56 ` Akira Yokosawa
2022-05-09 22:37 ` Jonathan Corbet
2022-05-10 11:57 ` Miguel Ojeda
2022-05-09 22:32 ` Jonathan Corbet
2022-05-10 3:14 ` Gaelan Steele
2022-05-10 5:53 ` Josh Triplett
2022-05-11 13:49 ` Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 19/23] Kbuild: add Rust support Miguel Ojeda
2022-05-07 5:24 ` Miguel Ojeda
2022-05-07 5:24 ` Miguel Ojeda
2022-05-07 5:24 ` Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 20/23] samples: add Rust examples Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 21/23] MAINTAINERS: Rust Miguel Ojeda
2022-05-07 8:06 ` Kees Cook
2022-05-07 5:24 ` [PATCH v6 22/23] [RFC] drivers: gpio: PrimeCell PL061 in Rust Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 23/23] [RFC] drivers: android: Binder IPC " Miguel Ojeda
2022-05-07 7:55 ` Kees Cook
2022-05-07 8:13 ` Greg Kroah-Hartman
2022-05-09 17:52 ` Todd Kjos
2022-05-07 8:06 ` [PATCH v6 00/23] Rust support Kees Cook
2022-05-07 8:06 ` Kees Cook
2022-05-07 8:06 ` Kees Cook
2022-05-07 8:06 ` Kees Cook
2022-05-08 18:06 ` Matthew Wilcox
2022-05-08 18:06 ` Matthew Wilcox
2022-05-08 18:06 ` Matthew Wilcox
2022-05-08 18:06 ` Matthew Wilcox
2022-05-09 9:39 ` Wei Liu
2022-05-09 9:39 ` Wei Liu
2022-05-09 9:39 ` Wei Liu
2022-05-09 9:39 ` Wei Liu
2022-05-07 9:29 ` David Gow
2022-05-07 9:29 ` David Gow
2022-05-07 9:29 ` David Gow
2022-05-07 9:29 ` David Gow
2022-05-07 15:03 ` Miguel Ojeda
2022-05-07 15:03 ` Miguel Ojeda
2022-05-07 15:03 ` Miguel Ojeda
2022-05-07 15:03 ` Miguel Ojeda
2022-05-10 4:44 ` David Gow
2022-05-10 4:44 ` David Gow
2022-05-10 4:44 ` David Gow
2022-05-10 4:44 ` David Gow
2022-05-10 11:36 ` Miguel Ojeda [this message]
2022-05-10 11:36 ` Miguel Ojeda
2022-05-10 11:36 ` Miguel Ojeda
2022-05-10 11:36 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANiq72mcvKDW6qO=1PzYR_U0tAwVLyCWFZjFVLL81znWDSYq7A@mail.gmail.com' \
--to=miguel.ojeda.sandonis@gmail.com \
--cc=davidgow@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko@kernel.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=live-patching@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.