The Linux Kernel Mailing List
 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, Jeremy Bingham <jbingham@gmail.com>
Subject: [PATCH 0/3] minix: convert to iomap and add direct I/O
Date: Thu, 25 Jun 2026 14:48:02 -0700	[thread overview]
Message-ID: <cover.1782422707.git.jbingham@gmail.com> (raw)

This series converts the minix filesystem from the buffer_head-based
I/O path to the iomap API, and adds direct I/O support in the process.

The conversion is straightforward: minix's indirect block tree mapping
logic (from itree_common.c) is reworked into an iomap_begin/iomap_end
implementation.  The iomap_end callback is a no-op since minix has no
extents or transactions to finalize.

Patch 1 adds the iomap infrastructure: the new iomap.c file, wrapper
functions and iomap_ops structs in itree_v1.c and itree_v2.c, and the
relevant declarations in minix.h.

The iomap.c file is #include'd into itree_v1.c and itree_v2.c rather
than compiled as a standalone translation unit.  This is because the
minix filesystem versions (V1 vs V2/V3) have different block_t sizes
(16-bit vs 32-bit) and different indirect tree depths.  This follows
the existing pattern in minix where itree_common.c is included into
both itree_v1.c and itree_v2.c.  Each version provides a thin wrapper
and a corresponding iomap_ops struct.

Patch 2 converts the regular file address space operations to iomap:
read_folio, readahead, writepages (with a writeback callback), bmap,
and folio lifecycle helpers.  Directory inodes continue to use
buffer_head-based operations via a new minix_dir_aops, since directory
handling still relies on buffer head chunks for prepare/write_begin.

Patch 3 converts the file_operations: replacing the generic read/write
iterators with iomap-aware versions, adding direct I/O read/write paths
using iomap_dio_rw, and setting FMODE_CAN_ODIRECT in the open handler.

The minix iomap implementation was adapted from the out-of-tree xiafs
iomap conversion. The xiafs module itself borrowed heavily from the
modernized minix kernel module.  The exfat iomap changes were an
additional reference for both conversions.

This has been compile-tested and put through basic runtime testing:
creating files, creating directories, writing and reading files,
removing files and directories, and files and directory structures
persisting after unmounting and remounting all work for all versions
of the minix filesystem. 

Signed-off-by: Jeremy Bingham <jbingham@gmail.com>

Jeremy Bingham (3):
  minix: add iomap infrastructure
  minix: convert address space operations to iomap
  minix: convert file operations to iomap and add direct I/O

 fs/minix/file.c     | 153 ++++++++++++++++++++++++++++++++++++++++++--
 fs/minix/inode.c    |  83 ++++++++++++++++++++++--
 fs/minix/iomap.c    | 114 +++++++++++++++++++++++++++++++++
 fs/minix/itree_v1.c |  25 +++++++-
 fs/minix/itree_v2.c |  17 ++++-
 fs/minix/minix.h    |  22 ++++++-
 6 files changed, 398 insertions(+), 16 deletions(-)
 create mode 100644 fs/minix/iomap.c

-- 
2.47.3

             reply	other threads:[~2026-06-25 21:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-25 21:48 Jeremy Bingham [this message]
2026-06-25 21:48 ` [PATCH 1/3] minix: add iomap infrastructure Jeremy Bingham
2026-06-25 21:48 ` [PATCH 2/3] minix: convert address space operations to iomap Jeremy Bingham
2026-06-25 21:48 ` [PATCH 3/3] minix: convert file operations to iomap and add direct I/O Jeremy Bingham
2026-06-26  7:07 ` [syzbot ci] Re: minix: convert " syzbot ci
2026-06-26 19:25   ` 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.1782422707.git.jbingham@gmail.com \
    --to=jbingham@gmail.com \
    --cc=brauner@kernel.org \
    --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