All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Keith Busch <kbusch@meta.com>,
	linux-block@vger.kernel.org, shinichiro.kawasaki@wdc.com
Subject: Re: [PATCH blktests] create a test for direct io offsets
Date: Tue, 14 Oct 2025 15:59:38 -0600	[thread overview]
Message-ID: <aO7HyvtEXv6h37PI@kbusch-mbp> (raw)
In-Reply-To: <ac0c15bb-7679-490a-93aa-ffdc7635ec3f@acm.org>

On Tue, Oct 14, 2025 at 02:21:20PM -0700, Bart Van Assche wrote:
> On 10/14/25 1:54 PM, Keith Busch wrote:
> > +static void find_mount_point(const char *filepath, char *mount_point,
> > +			     size_t mp_len)
> > +{
> > +	char path[PATH_MAX - 1], abs_path[PATH_MAX], *pos;
> > +	struct stat file_stat, mp_stat, parent_stat;
> 
> Why C instead of C++? Any code that manipulates strings is usually
> significantly easier to write in C++ rather than C.

The only reason I have is that I'm not a very good C++ coder.
 
> > +	strncpy(mount_point, path, mp_len - 1);
> > +	mount_point[mp_len - 1] = '\0';
> 
> Why strncpy() instead of strdup()?

I'm just using stack strings here, avoiding any heap allocations.

> > +	else if (len >= 4 && p > base && p < base + len - 1) {
> > +		if ((strncmp(base, "sd", 2) == 0 ||
> > +		     strncmp(base, "hd", 2) == 0 ||
> > +		     strncmp(base, "vd", 2) == 0) &&
> > +		     (*p >= 'a' && *p <= 'z'))
> > +			*(p + 1) = '\0';
> > +	}
> 
> Deriving the disk name from a partition name by stripping a suffix is
> fragile.

Completely agree.

> A better way is to iterate over /sys/class/block/*/*. See also
> the PartitionParent() function in https://cs.android.com/android/platform/superproject/main/+/main:system/core/fs_mgr/blockdev.cpp.

Thanks for the pointer.

> > +static void read_sysfs_attr(char *path, unsigned long *value)
> > +{
> > +	FILE *f;
> > +	int ret;
> > +
> > +	f = fopen(path, "r");
> > +	if (!f)
> > +		err(ENOENT, "%s", path);
> > +
> > +	ret = fscanf(f, "%lu", value);
> > +	fclose(f);
> > +	if (ret != 1)
> > +		err(ENOENT, "%s", basename(path));
> > +}
> 
> Why is the result stored in a pointer argument instead of returning it
> as return value?

No particular reason.
 
> > +static void read_queue_attrs(const char *path)
> > +{
> > +	char attr[PATH_MAX];
> > +
> > +	if (snprintf(attr, sizeof(attr), "%s/max_segments", path) < 0)
> > +		err(errno, "max_segments");
> > +	read_sysfs_attr(attr, &max_segments);
> 
> Has it been considered to make read_sysfs_attr() accept a format string
> + arguments? I think that would make the code in this function more
> compact.

That sounds good to me.

Though all the comments are about the boiler plate parameter extraction.
That was supposed to be the least interesting part about this patch :)

  reply	other threads:[~2025-10-14 21:59 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 [this message]
2025-10-17 11:13 ` Christoph Hellwig
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=aO7HyvtEXv6h37PI@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=bvanassche@acm.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 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.