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:
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?
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.
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.
So are there really code which is doing a printf of 'PRIino "d"'? Or was this to allow the use of of 'PRiino "x"'?
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.