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: > > 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. > > 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.
