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. -- Jeff Layton <[email protected]>
