Linux filesystem development
 help / color / mirror / Atom feed
From: Jeremy Bingham <jbingham@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, brauner@kernel.org,
	jkoolstra@xs4all.nl, jack@suse.cz, djwong@kernel.org,
	Jeremy Bingham <jbingham@gmail.com>
Subject: [RFC PATCH 0/1] minix: unify itree_v1, itree_v2, and itree_common
Date: Mon,  6 Jul 2026 01:35:35 -0700	[thread overview]
Message-ID: <cover.1783324260.git.jbingham@gmail.com> (raw)

For as far back as the git history goes and then some, minix's itree
functions have been split across three files: itree_v1.c, itree_v2.c,
and itree_common.c. The first two of these files had defines, types, static
helper functions, and some wrapper functions tailored for version 1 and
versions 2 and 3 of the Minix file systems respectively. Each of these
files then included itree_common.c.

The reason for this odd arrangement is that there are some stark
differences between version 1 and versions 2 and 3 of the Minix fs.
Version 1 has doubly indirect blocks and 16 bit block pointers, while
versions 2 and 3 have trebly indirect blocks and 32 bit block pointers.
By having the separate itree_v1.c and itree_v2.c files that then
included itree_common.c, DIRECT, DEPTH, block_t, and Indirect could be
defined differently for the two broad types of Minix filesystems while
sharing the bulk of their code because the same code in itree_common.c
would be treated differently by the preprocessor and compiler depending
on which file included it. In other words, DEPTH could mean 3 or 4
depending on if it had been included from itree_v1.c or itree_v2.c.

This whole thing came up while some patches I submitted recently to move
minix over to use iomap were being reviewed. Having the two separate
code paths and includes made that task much more difficult, and a
reviewer commented at one part about how it was one way to avoid keeping
disk geometry information in the superblock info struct. Parts of this
code do not seem to have been modified for a very, very long time,
possibly since 1991, but that's no reason necessarily to keep it in place.

This patch unifies the two code paths previously used for itree
functions. Most of it runs the same no matter what version of the
filesystem is being used, but in the places where it doesn't version
checks, information stored in the superblock, dynamically allocating
formerly static arrays, careful pointer casting, and judicious use of
accessor functions for more type safety handle the different cases while
still keeping the code more contained and hopefully less confusing to
others.

As this is an RFC patch, there are many more comments explaning my
thought processes and what's going on than would usually be found in a
kernel patch submission. Depending on how this is received, I will clean
out excessive comments before submitting it for real.

This file unavoidably lands as one relatively large patch, but it ended
up not breaking down well into smaller chunks that would still build a
working kernel.

Jeremy Bingham (1):
  minix: unify the v1 and v2/v3 itree code paths

 fs/minix/Makefile       |   2 +-
 fs/minix/inode.c        |  35 +-
 fs/minix/itree.c        | 744 ++++++++++++++++++++++++++++++++++++++++
 fs/minix/itree_common.c | 374 --------------------
 fs/minix/itree_v1.c     |  67 ----
 fs/minix/itree_v2.c     |  75 ----
 fs/minix/minix.h        |  26 +-
 7 files changed, 774 insertions(+), 549 deletions(-)
 create mode 100644 fs/minix/itree.c
 delete mode 100644 fs/minix/itree_common.c
 delete mode 100644 fs/minix/itree_v1.c
 delete mode 100644 fs/minix/itree_v2.c

-- 
2.47.3


             reply	other threads:[~2026-07-06  8:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06  8:35 Jeremy Bingham [this message]
2026-07-06  8:35 ` [RFC PATCH 1/1] minix: unify the v1 and v2/v3 itree code paths Jeremy Bingham

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=cover.1783324260.git.jbingham@gmail.com \
    --to=jbingham@gmail.com \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --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