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:

quoted

On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:

quoted

On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:

quoted

On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:

quoted

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.