Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro

Matthew Wilcox <[email protected]> Tue, 3 Mar 2026 17:18:30 +0000
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,gmane.linux.bluez.kernel,gmane.linux.can,gmane.linux.kernel.bpf
Message-ID <[email protected]>
On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:
> 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

4/ Don't do anything, drop the patch series (I'm not in favour of this,
but it is an option)

5/ Do the conversion(s) _once_ per filesystem.  Here's one way to do
it:

-	unsigned long           i_ino;
+	union {
+		u64 i_ino64;
+		struct {
+#if defined(CONFIG_64BIT)
+			unsigned long i_ino;
+#elif defined(CONFIG_CPU_BIG_ENDIAN)
+			unsigned long i_ino;
+			unsigned long i_ino_pad;
+#else
+			unsigned long i_ino_pad;
+			unsigned long i_ino;
+#endif
+		};
+	};

[...]
#define i_ino(inode)	(inode)->i_ino64

So that's patch one.  All plain references to i_ino access the lower
bits of i_ino64, so everything will continue to work as it does today.

Once you've got the VFS core in shape, you can convert filesystems one
at a time to use i_ino(inode).  Once you're done you can delete the
scaffolding from the core and go back to calling i_ino64 just i_ino.
You could delete the i_ino() uses from filesystems at that point, but
why bother?

I'm sure there are other ways to do it, this is just the one I came up
with.  But for the love of god stop spamming hundreds of people on the
cc of this patchset.  In fact, take me off for next time -- I get each
one of these fucking patches four times.