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

On Tue, 2026-03-03 at 10:16 -0500, Theodore Tso wrote:
> On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> >=20
> > 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?
>=20
> I didn't realize that this was going to disappear in the end.  That
> makes me feel much better about the change.  I'd suggest changing the
> commit description where it claims that we're using something that
> follows the inttypes.h convention and making it clear that this is
> temporary and only to preserve bisectability.
>=20
> One question though --- are there *really* places that are using
> signed inode numbers and trying to print them?  If people are trying
> to use negative inodes to signal an error or some such, the it implies
> that at least for some file systems, an inode number larger than 2**63
> might be problematic.  If there is core VFS code that uses a negative
> inode number then this could be a real potential trap.
>=20
> So are there really code which is doing a printf of 'PRIino "d"'?  Or
> was this to allow the use of of 'PRiino "x"'?
>=20

Mostly it's to allow 'PRIino "x"'. There are a number of places that
(for whatever reason) print the inode number in hex. I don't want to
change those.

There are also some places that print it as a signed value (PRIino
"d"). I suspect most of those are bugs, or just holdovers from a
simpler time when we didn't worry so much about the signedness of inode
numbers. I fixed a few of those in the context of this series, fwiw.

--=20
Jeff Layton <[email protected]>