public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Keith Busch <kbusch@meta.com>
Cc: linux-block@vger.kernel.org, shinichiro.kawasaki@wdc.com,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH blktests] create a test for direct io offsets
Date: Fri, 17 Oct 2025 04:13:32 -0700	[thread overview]
Message-ID: <aPIk3Ng8JXs-3Pye@infradead.org> (raw)
In-Reply-To: <20251014205420.941424-1-kbusch@meta.com>

> +static void init_kernel_version()
> +{
> +	struct utsname buffer;
> +	char *major_version_str;
> +	char *minor_version_str;
> +	if (uname(&buffer) != 0)
> +		err(errno, "uname");
> +
> +	major_version_str = strtok(buffer.release, ".");
> +	minor_version_str = strtok(NULL, ".");
> +
> +	kernel_major = strtol(major_version_str, NULL, 0);
> +	kernel_minor = strtol(minor_version_str, NULL, 0);
> +}

Testing for specific kernel versions is probably going to fall
flat when this stuff gets backported..  I just realize that maybe
we just need a statx / fsxattr flag to report that this is supported
to make everyones life easier?  statx probably won't make Christian
happy, but now that the fsxattr stuff is in common code that seems
like an easy enough option to rush into 6.18 still.

I.e., we should find a way to remove all the need to find the kernel
version, mount point and bdev from mountpoint.  Especially as the
latter won't work for multi-device configurations like btrfs or
the XFS rtdev.  My rule of thumb for new I/O path features is that
the application should be able to discover everything it needs just
using the FD used for I/O as that is a huge differenciator for
usability.


  parent reply	other threads:[~2025-10-17 11:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14 20:54 [PATCH blktests] create a test for direct io offsets Keith Busch
2025-10-14 21:21 ` Bart Van Assche
2025-10-14 21:59   ` Keith Busch
2025-10-17 11:13 ` Christoph Hellwig [this message]
2025-10-20 16:20   ` Keith Busch
2025-10-21  5:28     ` Christoph Hellwig
2025-10-21 21:22       ` Keith Busch
2025-10-22  4:46         ` Christoph Hellwig
2025-11-17 21:53           ` Keith Busch
2025-11-18  5:54             ` Christoph Hellwig
2025-10-20 12:40 ` Shinichiro Kawasaki
2025-10-20 21:03   ` Keith Busch
2025-10-21  1:32     ` Shinichiro Kawasaki
2025-10-20 23:25 ` Chaitanya Kulkarni

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=aPIk3Ng8JXs-3Pye@infradead.org \
    --to=hch@infradead.org \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-block@vger.kernel.org \
    --cc=shinichiro.kawasaki@wdc.com \
    /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