Re: [PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64
Mathieu Desnoyers <[email protected]> Fri, 27 Feb 2026 14:01:25 -0500
| Newsgroups | org.kernel.vger.autofs,dev.linux.lists.fsverity,dev.linux.lists.netfs,dev.linux.lists.ntfs3,dev.linux.lists.nvdimm,dev.linux.lists.ocfs2-devel,dev.linux.lists.v9fs,net.sourceforge.lists.linux-f2fs-devel,org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-mtd,org.kernel.vger.ceph-devel,org.kernel.vger.ecryptfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fscrypt,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-hams,org.kernel.vger.linux-integrity,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.linux-nfs,org.kernel.vger.linux-nilfs,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-security-module,org.kernel.vger.linux-trace-kernel,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-x25,org.kernel.vger.linux-xfs,org.kernel.vger.netdev,org.kernel.vger.selinux,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 2026-02-27 12:19, Jeff Layton wrote: > On Thu, 2026-02-26 at 16:49 +0000, Matthew Wilcox wrote: >> On Thu, Feb 26, 2026 at 10:55:02AM -0500, Jeff Layton wrote: >>> The bulk of the changes are to format strings and tracepoints, since the >>> kernel itself doesn't care that much about the i_ino field. The first >>> patch changes some vfs function arguments, so check that one out >>> carefully. >> >> Why are the format strings all done as separate patches? Don't we get >> bisection hazards by splitting it apart this way? > > Circling back to this... > > I have a v2 series (~107 patches) that I'm testing now that does this > more bisectably with the typedef and macro scaffolding that Mathieu > suggested. I'll probably send it early next week. > > I had done it this way originally since I figured it was best to break > this up by subsystem. Should I continue with this series as a set of > patches broken up this way, or is it preferable to combine the pile of > format changes into fewer patches? Here is the approach I would recommend to maximize signal over noise for the follow up email thread discussions: Now that your series is bisectable, you could post a [RFC PATCH v2] series with the following: - Patch 00 introduces the series, points to your git branch implementing the whole series, - The first few patches introduce the new type (kino_t) and macro to do the format string transition. Initially kino_t would typedef to unsigned long (no changes). - Followed by patches implementing the type + format string changes for a few key subsystems. - The final patch would change kino_t and the format string macro to 64-bit integers. Once everyone agree on those core changes, you could proceed to post patches that change additional subsystems in a subsequent round. One more comment: have you tried using Coccinelle to do this kind of semantic code change ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com