Re: [PATCH v4 2/3] minix: add iomap functions and definitions

[Christoph Hellwig <hch@infradead.org>]

On Sat, Sep 19, 2026 at 10:51:32AM -0700, Jeremy Bingham wrote:
> On Fri, Sep 18, 2026 at 7:12 AM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > 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
> 
> OK. I went back and forth a bunch on how to best do this, because it's *such* a mess.

Agreed.

> I had a lot of reservations about the way I had done it, but
> it's so all around
> messy I ended up there. When I refactor it I'll either move that function to
> itree_common.c or craft a way to get that depth information out.

It might be worthwhile to kill this mess off first.  AFAICS it was
written at a time when branch predictors where much worse than
today.  So having a branch for te two cases much lower down in the code
should be just fine with modern CPUs. 

> 
> > > 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.
> 
> Noted. I did submit a patch like that back in I think late June or
> early July, but got
> told (politely) to knock it off. I had kept these cleanups because of
> checkpatch.pl
> griping, but as you said below there's no technical downside to leaving it.

checkpatch.pl is a little weird sometimes unfortunately.