Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig <hch@infradead.org>
Date: 2026-03-03 14:00:14
Also in:
amd-gfx, autofs, bpf, ceph-devel, linux-can, linux-cifs, linux-ext4, linux-f2fs-devel, linux-fscrypt, linux-fsdevel, linux-hams, linux-integrity, linux-media, linux-mm, linux-nfs, linux-perf-users, linux-sctp, linux-security-module, linux-trace-kernel, linux-unionfs, linux-xfs, lkml, netdev, netfs, ntfs3, nvdimm, ocfs2-devel, selinux, v9fs
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: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.