mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v1 0/1] minix: unify the v1 and v2/v3 itree code paths
@ 2026-09-28 20:04 Jeremy Bingham
  2026-09-28 20:04 ` [PATCH v1 1/1] minix: consolidate itree* files into one itree.c file Jeremy Bingham
  0 siblings, 1 reply; 2+ messages in thread
From: Jeremy Bingham @ 2026-09-28 20:04 UTC (permalink / raw)
  To: linux-fsdevel
  Cc: linux-kernel, brauner, jkoolstra, jack, djwong, hch, viro,
	Jeremy Bingham

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-09-28 20:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-28 20:04 [PATCH v1 0/1] minix: unify the v1 and v2/v3 itree code paths Jeremy Bingham
2026-09-28 20:04 ` [PATCH v1 1/1] minix: consolidate itree* files into one itree.c file Jeremy Bingham

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®