From: Christoph Hellwig <hch@infradead.org>
To: Jeremy Bingham <jbingham@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
brauner@kernel.org, jkoolstra@xs4all.nl, jack@suse.cz,
djwong@kernel.org, viro@zeniv.linux.org.uk, hch@infradead.org
Subject: Re: [PATCH v4 2/3] minix: add iomap functions and definitions
Date: Fri, 18 Sep 2026 07:12:00 -0700 [thread overview]
Message-ID: <aq1GsO6dkS747OEb@infradead.org> (raw)
In-Reply-To: <e7ab836149f814b04017905dca2e07a4c94078db.1787770110.git.jbingham@gmail.com>
On Wed, Aug 26, 2026 at 02:41:56PM -0700, Jeremy Bingham wrote:
> This patch also wires iomap.c into itree_v1.c and itree_v2.c, similarly
> to how itree_common.c is included in those files, and exports version
> specific versions of minix_iomap_begin and iomap_ops.
Can we keep the iomap code out of this double build mess? Just define
some low-level helper in it, but keep everything else in an only
once build iomap.c
> Also updates 'unsigned' to 'unsigned int' a few places that got picked
> up by checkpatch.pl.
If you want to do these cleanups please split them into a separate
patch.
> +++ b/fs/minix/iomap.c
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * iomap functions for minix.
> + */
Not really a very useful comment :) OTOH this lacks a copyright
statement for your work.
> +static int minix_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
> + unsigned int flags, struct iomap *iomap, struct iomap *srcmap)
This mostly does not need the iomap. It basically returns a physical
block and a trystate of HOLE/FOUND/ALLOCATED. If you change the
interface to that you can keep it in itree_common by directly morphing
the existing block lookup into that, or even do it as a prep patch,
which first refactors get_block to this interface, and then do the
iomap mapping on top of that, and in a place that only gets built
once.
> +/*
> + * minix_iomap_end ends up being a nop; since minix doesn't have any extents or
> + * transactions to worry about, there isn't anything to update here. The on-disk
> + * indirect blocks get dirtied in minix_iomap_begin.
> + */
> +static int minix_iomap_end(struct inode *inode, loff_t offset, loff_t length,
> + ssize_t written, unsigned int flags, struct iomap *iomap)
> +{
> + return 0;
> +}
In which case we can just drop it. Note that for the next version
against 7.3-rc should also move from the begin/end calls to the
single next one using the DEFINE_IOMAP_ITER_NEXT helper macro.
> -static inline unsigned minix_blocks_needed(unsigned bits, unsigned blocksize)
> +static inline unsigned int minix_blocks_needed(unsigned int bits, unsigned int blocksize)
Overly long line. I'd much rather generate the baseless checkpath.pl
complaint and leave the plain unsgineds in place. There is absolutely
no technical downside in using that notation.
> +static inline const struct iomap_ops *minix_iomap_ops_ver(struct inode *inode)
> +{
> + return (INODE_VERSION(inode) == MINIX_V1) ?
No need for the braces.
next prev parent reply other threads:[~2026-09-18 14:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 21:41 [PATCH v4 0/3] minix: convert to iomap Jeremy Bingham
2026-08-26 21:41 ` [PATCH v4 1/3] iomap: add iomap_symlink_write Jeremy Bingham
2026-09-18 13:48 ` Christoph Hellwig
2026-08-26 21:41 ` [PATCH v4 2/3] minix: add iomap functions and definitions Jeremy Bingham
2026-09-18 14:12 ` Christoph Hellwig [this message]
2026-08-26 21:41 ` [PATCH v4 3/3] minix: finish wiring in iomap functions Jeremy Bingham
2026-09-18 15:10 ` Christoph Hellwig
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=aq1GsO6dkS747OEb@infradead.org \
--to=hch@infradead.org \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=jbingham@gmail.com \
--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®