public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Ming Lei <[email protected]>
Cc: [email protected], [email protected],
	Keith Busch <[email protected]>,
	[email protected]
Subject: Re: [PATCH V3 0/3] selftests: add ublk selftests
Date: Fri, 28 Feb 2025 19:19:37 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <Z8JexssISF2zsNRv@fedora>

On 2/28/25 6:11 PM, Ming Lei wrote:
> On Fri, Feb 28, 2025 at 09:37:47AM -0700, Jens Axboe wrote:
>> On 2/28/25 9:19 AM, Ming Lei wrote:
>>> Hello Jens,
>>>
>>> This patchset adds ublk kernel selftests, which is very handy for
>>> developer for verifying kernel change, especially ublk heavily depends
>>> on io_uring subsystem. Also it provides template for target implementation.
>>>
>>> Please consider it for v6.15.
>>
>> Can we add the zc bits to the liburing test case as well?
> 
> OK, will unify the two tests and cover liburing too.
> 
> BTW, would you like to consider to move liburing tests or part of them
> into kernel selftests? 
> 
> This way looks more friendly for kernel developer:
> 
> - single repo, and single patchset can include both io_uring kernel
>   patches and selftests change
> 
> - easy to run test against same kernel repo

I have considered it, but at least the way I run the liburing tests, it
uses a bunch of different types of devices to get full coverage. It's
not really a fire-off-and-forget kind of setup. Yes you can run it like
that and not have it use any other fs or device, but you won't get full
coverage. The liburing regression tests are also meant to be run on ANY
kernel, not just the current kernel. Eg I do that for stable kernels.

As far as I can tell, the only win here would be that it'd be easier for
someone to run when making a kernel change. And that is a nice win
indeed. But there are so many downsides for me and the tests in general,
that I don't see that win as being nearly big enough to warrant
switching it over.

For new feature tests, I think adding that as kernel selftests may make
more sense - test that it works, test failure/error cases, etc.

> Also liburing development may be decoupled from io_uring kernel
> a bit.

It's already entirely decoupled from the kernel. At least as much as it
can be. Yes the uapi header is shared and synced across them, but
there's really no other dependency there and no version dependencies
between liburing and the kernel.

-- 
Jens Axboe

      reply	other threads:[~2025-03-01  2:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <[email protected]>
     [not found] ` <[email protected]>
2025-03-01  1:11   ` [PATCH V3 0/3] selftests: add ublk selftests Ming Lei
2025-03-01  2:19     ` Jens Axboe [this message]

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox