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 | gmane.comp.file-systems.ecryptfs.general,gmane.linux.file-systems,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.comp.file-systems.ext4,gmane.linux.file-systems.f2fs,gmane.linux.nfs,gmane.linux.kernel.cifs,gmane.network.samba.internals,gmane.comp.file-systems.nilfs.user,gmane.linux.kernel.autofs,gmane.comp.file-systems.ceph.devel,gmane.comp.file-systems.coda.general,gmane.linux.drivers.mtd,gmane.linux.file-systems.union,gmane.comp.security.apparmor,gmane.linux.kernel.lsm,gmane.comp.freedesktop.amd-gfx,gmane.comp.video.dri.devel,gmane.linux.drivers.video-input-infrastructure,gmane.linux.network,gmane.linux.kernel.perf.user,gmane.linux.hams,gmane.linux.x25 |
|---|---|
| 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