On Tue, Mar 03, 2026 at 10:14:27AM -0500, Jeff Layton wrote:

On Tue, 2026-03-03 at 06:30 -0800, Christoph Hellwig wrote:

quoted

On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:

quoted

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.

Well, I've done 2 and 3 already. Why not 1? :)

It's not so much the regressions that are a problem here, but the merge
conflicts for anyone wanting to backport later patches that are near
these format changes. Having that change broken up by subsystem makes
it easier to handle that piecemeal later.

I think we'll be looking at close to a 1000 line patch that touches
nearly 200 files if go that route. Roughly:

 182 files changed, 910 insertions(+), 912 deletions(-)

There are some tracepoint changes in some of the per-subsystem patches
that will need to be split out, so the count isn't exact, but it'll be
fairly close.

Since Christian will probably end up taking this series, I'd like to
get his opinion before I respin anything.

I'm kinda surprised that we suddenly started caring about the amount of
individual patches. I personally don't care either way. Do it in one
giant patch if this moves us forward. I've done 1 and 3 and what you
did. And I'd be really annoyed if during a bisect I start to get
pointless build failures because someone did 2.