Re: [f2fs-dev] [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro

[Christoph Hellwig <hch@infradead.org>]

On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:
> On Tue, 2026-03-03 at 05:59 -0800, Christoph Hellwig wrote:
> > On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> > > On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > > > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > > > overlook the bikeshed's color in this instance?
> > > > 
> > > > So why add it in the first place?  
> > > 
> > > Bisectability. The first version I did of this would have broken the
> > > ability to bisect properly across these changes. I don't love the
> > > "churn" here either, but this should be cleanly bisectable.
> > 
> > What do you need to bisect in format string changes?  Splitting
> > every variable type change outside of the main i_ino out - sure.
> > But bisecting that "change to u64 in ext4" really broke ext4 and
> > not "change to u64" is not very useful.  Commits should do one
> > well defined thing.  Adding a weird transition layer for a format
> > thing that just gets dropped is not one well defined thing.
> 
> In the middle stages of the series, you will get warnings or errors on
> 32-bit hosts when i_ino's type doesn't match what the format string
> expects.
> 
> There are really only three options here:
> 
> 1/ Do (almost) all of the changes in one giant patch
> 
> 2/ Accept that the build may break during the interim stages
> 
> 3/ This series: using a typedef and macro to work around the breakage
> until the type can be changed, at the expense of some extra churn in
> the codebase
> 
> 3 seems like the lesser evil.

No, 1 is by far the least evil.  Note that it's not really almost all,
as all the local variables can easily and sanely be split out.  It's
all of the format strings, and that makes sense.  The only "regressions"
there are incorrect format strings which have good warnings and can
be fixed easily.



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel