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