Re: [PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64

Jeff Layton <[email protected]> Fri, 27 Feb 2026 12:19:02 -0500
Newsgroups gmane.comp.file-systems.ext4,gmane.linux.file-systems,gmane.linux.kernel,gmane.linux.kernel.mm,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.comp.file-systems.ecryptfs.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 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?
-- 
Jeff Layton <[email protected]>