The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] minix: unify itree_v1, itree_v2, and itree_common
@ 2026-07-06  8:35 Jeremy Bingham
  2026-07-06  8:35 ` [RFC PATCH 1/1] minix: unify the v1 and v2/v3 itree code paths Jeremy Bingham
  0 siblings, 1 reply; 2+ messages in thread
From: Jeremy Bingham @ 2026-07-06  8:35 UTC (permalink / raw)
  To: linux-fsdevel
  Cc: linux-kernel, brauner, jkoolstra, jack, djwong, 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.

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


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

end of thread, other threads:[~2026-07-06  8:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox