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,
hch@infradead.org, viro@zeniv.linux.org.uk,
Jeremy Bingham <jbingham@gmail.com>
Subject: [PATCH v1 0/1] minix: unify the v1 and v2/v3 itree code paths
Date: Mon, 28 Sep 2026 13:04:25 -0700 [thread overview]
Message-ID: <cover.1790359547.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.
Christoph Hellwig theorized that minix has this unusual arrangement
because this code was written at a time when the branch predictors were
much worse than today. This makes sense to me, at least as much sense as
can be expected, and I agree with him that modern CPUs should be able to
handle a branch for the two cases lower down in the code. At this point,
the possible performance boost for a historic filesystem that is at best
unlikely to be being used in production anywhere should not outweigh the
benefits for readability and maintainability that unifying the itree
code paths would bring.
This patch was verified against the minix xfstests-dev branch[1] used
for verifying the minix iomap patches. After applying this patch, the
minix tests have the same results as the baseline: v1 and v3 outright
fail generic/472 (a swapfile test), while v2 passes. This does not
include the collection of tests skipped by xfstests because minix will
never, ever be able to pass them because of limitations inherent to the
filesystems. Functionally, the minix module is identical before and
after the patch is applied.
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.
[1]: https://github.com/ctdk/xfstests-dev/tree/minix
Jeremy Bingham (1):
minix: consolidate itree* files into one itree.c file
fs/minix/Makefile | 2 +-
fs/minix/inode.c | 38 +--
fs/minix/itree.c | 672 ++++++++++++++++++++++++++++++++++++++++
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, 702 insertions(+), 552 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
next reply other threads:[~2026-09-28 20:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 20:04 Jeremy Bingham [this message]
2026-09-28 20:04 ` [PATCH v1 1/1] minix: consolidate itree* files into one itree.c file Jeremy Bingham
2026-10-05 8:18 ` Christoph Hellwig
2026-10-05 19:45 ` 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.1790359547.git.jbingham@gmail.com \
--to=jbingham@gmail.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jkoolstra@xs4all.nl \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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®