All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jeremy Bingham <jbingham@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	brauner@kernel.org, jkoolstra@xs4all.nl, jack@suse.cz,
	djwong@kernel.org
Subject: Re: [RFC PATCH 1/1] minix: unify the v1 and v2/v3 itree code paths
Date: Tue, 22 Sep 2026 06:01:38 -0700	[thread overview]
Message-ID: <arJ8Mpef2gSLvKos@infradead.org> (raw)
In-Reply-To: <d9f07a9037d019043ed24d8245d9a58ce2c669f0.1783324260.git.jbingham@gmail.com>

I think this is a good idea, and should make the code more maintainable
forward, as well as simply your iomap conversion.

A few comments:

> +	/* Set the direct block and indirect block depth now that the rest of
> +	 * the version-specific settings have been set.
> +	 */

Please use the normal kernel comment style:

	/*
	 * Set the direct block and indirect block depth now that the rest of
	 * the version-specific settings have been set.
	 */

> +	sbi->s_direct = MINIX_DIRECT; /* Always the same. */

No need for the comment I think.

>  	generic_fillattr(&nop_mnt_idmap, request_mask, inode, stat);
>  	if (INODE_VERSION(inode) == MINIX_V1)
> -		stat->blocks = (BLOCK_SIZE / 512) * V1_minix_blocks(stat->size, sb);
> +		stat->blocks = (BLOCK_SIZE / 512) * minix_blocks(stat->size, sb);
>  	else
> -		stat->blocks = (sb->s_blocksize / 512) * V2_minix_blocks(stat->size, sb);
> +		stat->blocks = (sb->s_blocksize / 512) * minix_blocks(stat->size, sb);

v1 always sets s_blocksize to BLOCK_SIZE, so this can simply become and
unconditional:

	stat->blocks = (sb->s_blocksize / 512) * minix_blocks(stat->size, sb);

> +++ b/fs/minix/itree.c
> @@ -0,0 +1,744 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + *  linux/fs/minix/inode.c

Please do not add (or move) file names in top of file comments,
they are a bit pointless.  Also we usually don't have an empty line
between the SPDX tag and the top of file comment.

> +#include <linux/slab.h>
> +#include "minix.h"
> +
> +#define DIRCOUNT 7
> +#define INDIRCOUNT(sb) (1 << ((sb)->s_blocksize_bits - 2))
> +#define MINIX_V1_BLK 512
> +#define MINIX_V1_BLK_SHIFT 9
> +
> +/* The different versions of the Minix filesystem also have different block
> + * sizes. In order to unify the itree functions and not have the split that's
> + * been in place for decades, we're going to have two separate types for v1 and
> + * v2/v3 block sizes. This does require having explicit version checks and
> + * casting block pointers to v1_block_t and a few cases where there's a special
> + * v1 version of a function that gets called where it's necessary to do it that
> + * way.

Comment usually should describe the current code and not the history.
There's a few exception where the history really matters like for bad
on-disk or on-wire formats set in stone.

> + * files, the last master commit before they were merged and altered was
> + * 87320be9f0d24fce67631b7eef919f0b79c3e45c.

Also not needed, git log/blame will tell us easily.

> +static inline int v2_block_to_path(struct inode *inode, long block, int *offsets)

Overly long line.  (a few more below)

> +/* same business with chain as before */
> +static inline int splice_branch(struct inode *inode,
> +				     Indirect *chain,
> +				     Indirect *where,
> +				     int num)

static inline int splice_branch(struct inode *inode, Indirect *chain,
		Indirect *where, int num)

Similar for a few other functions.

> +extern int minix_get_block(struct inode *inode, sector_t block,
> +		struct buffer_head *bh, int create);
> +extern unsigned int minix_blocks(loff_t size, struct super_block *sb);

Please drop the extern for all function declarations that you touch.


  parent reply	other threads:[~2026-09-22 13:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06  8:35 [RFC PATCH 0/1] minix: unify itree_v1, itree_v2, and itree_common Jeremy Bingham
2026-07-06  8:35 ` [RFC PATCH 1/1] minix: unify the v1 and v2/v3 itree code paths Jeremy Bingham
2026-08-16 21:17   ` kernel test robot
2026-09-22 13:01   ` Christoph Hellwig [this message]
2026-09-24 19:17     ` ctdk

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=arJ8Mpef2gSLvKos@infradead.org \
    --to=hch@infradead.org \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=jbingham@gmail.com \
    --cc=jkoolstra@xs4all.nl \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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.