mirror of https://lore.kernel.org/lkml/
 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.


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

Thread overview: 4+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®