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

[Jeff Layton <jlayton@kernel.org>]

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.
--
Jeff Layton <jlayton@kernel.org>