On Mon, 5 May 2025 at 05:54, Miguel Ojeda
wrote:
>
> 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
On Mon, 5 May 2025 at 03:02, Miguel Ojeda
wrote:
>
> 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 b
On Mon, 5 May 2025 at 02:00, Miguel Ojeda
wrote:
>
> 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 ab
On Sat, 3 May 2025 at 01:25, Shuah Khan wrote:
>
> When make finds the source tree unclean, it prints a message to run
> "make ARCH=x86_64 mrproper" message using the ARCH from the command
> line. The ARCH specified in the command line could be different from
> the ARCH of the existing build in th
On Sat, 3 May 2025 at 05:52, Miguel Ojeda wrote:
>
> 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:
On Sat, 3 May 2025 at 05:52, Miguel Ojeda wrote:
>
> 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 in
On Sat, 3 May 2025 at 05:52, Miguel Ojeda wrote:
>
> Since now we have support for returning `-> Result`s, we can convert some
> of these tests to use the feature, and serve as a first user for it too.
>
> Thus convert them.
>
> This, in turn, simplifies them a fair bit.
>
> We keep the actual ass
On Sat, 3 May 2025 at 05:52, Miguel Ojeda wrote:
>
> 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
> ---
I'm obviously a fan of this. Assuming
On Sat, 3 May 2025 at 05:52, Miguel Ojeda wrote:
>
> 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
On Sat, 3 May 2025 at 05:51, Miguel Ojeda wrote:
>
> Currently, return values of KUnit `#[test]` functions are ignored.
>
> Thus introduce support for `-> Result` functions by checking their
> returned values.
>
> At the same time, require that test functions return `()` or `Result E>`, which shou
On Sat, 3 May 2025 at 05:51, Miguel Ojeda wrote:
>
> The KUnit `#[test]` support that landed recently is very basic and does
> not map the `assert*!` macros into KUnit like the doctests do, so they
> panic at the moment.
>
> Thus implement the custom mapping in a similar way to doctests, reusing
>
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 Fri, Apr 25, 2025 at 01:59:57PM +0800, Jiayuan Chen wrote:
> When we specify apply_bytes, we divide the msg into multiple segments,
> each with a length of 'send', and every time we send this part of the data
> using tcp_bpf_sendmsg_redir(), we use sk_msg_return_zero() to uncharge the
> memory o
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 2:31 PM Miguel Ojeda
wrote:
>
> 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
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 2:15 PM Miguel Ojeda
wrote:
>
> 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 longe
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
On Fri, May 2, 2025 at 5:53 PM Miguel Ojeda wrote:
>
> The KUnit `#[test]` support that landed recently is very basic and does
> not map the `assert*!` macros into KUnit like the doctests do, so they
> panic at the moment.
>
> Thus implement the custom mapping in a similar way to doctests, reusing
On Fri, May 2, 2025 at 5:53 PM Miguel Ojeda wrote:
>
> Currently, return values of KUnit `#[test]` functions are ignored.
>
> Thus introduce support for `-> Result` functions by checking their
> returned values.
>
> At the same time, require that test functions return `()` or `Result E>`, which sh
On Fri, May 2, 2025 at 5:53 PM Miguel Ojeda wrote:
>
> In general, we should aim to test as much as possible within the actual
> kernel, and not in the build host.
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
On Fri, May 2, 2025 at 5:54 PM Miguel Ojeda wrote:
>
> Since now we have support for returning `-> Result`s, we can convert some
> of these tests to use the feature, and serve as a first user for it too.
>
> Thus convert them.
>
> This, in turn, simplifies them a fair bit.
>
> We keep the actual a
This patch refactors macros and non-composite global variable
definitions into a struct that is defined at the start of a test and is
passed around instead of relying on global vars.
Signed-off-by: Ujwal Kundur
---
Changes since v1:
- indentation fixes
- squash into single patch to assist bise
24 matches
Mail list logo
