Re: [PATCH v2 000/110] vfs: change inode->i_ino from unsigned long to u64
On Wed, 04 Mar 2026 17:26:59 +1100 NeilBrown wrote: > On Tue, 03 Mar 2026, Jeff Layton wrote: > > On Tue, 2026-03-03 at 10:55 +, David Howells wrote: > > > Jeff Layton wrote: > > > > > > > This version splits the change up to be more bisectable. It first adds a > > > > new kino_t typedef and a new "PRIino" macro to hold the width specifier > > > > for format strings. The conversion is done, and then everything is > > > > changed to remove the new macro and typedef. > > > > > > Why remove the typedef? It might be better to keep it. > > > > > > > Why? After this change, internel kernel inodes will be u64's -- full > > stop. I don't see what the macro or typedef will buy us at that point. > > Implicit documentation? > ktime_t is (now) always s64, but we still keep the typedef; > > It would be cool if we could teach vsprintf to understand some new > specifier to mean "kinode_t" or "ktime_t" etc. But that would trigger > gcc warnings. A more interesting one would be something that made gcc re-write the format with the correct 'length modifier' for the parameter. That would save a lot of effort! David > > NeilBrown >
Re: [PATCH v2 000/110] vfs: change inode->i_ino from unsigned long to u64
On Tue, 03 Mar 2026, Jeff Layton wrote: > On Tue, 2026-03-03 at 10:55 +, David Howells wrote: > > Jeff Layton wrote: > > > > > This version splits the change up to be more bisectable. It first adds a > > > new kino_t typedef and a new "PRIino" macro to hold the width specifier > > > for format strings. The conversion is done, and then everything is > > > changed to remove the new macro and typedef. > > > > Why remove the typedef? It might be better to keep it. > > > > Why? After this change, internel kernel inodes will be u64's -- full > stop. I don't see what the macro or typedef will buy us at that point. Implicit documentation? ktime_t is (now) always s64, but we still keep the typedef; It would be cool if we could teach vsprintf to understand some new specifier to mean "kinode_t" or "ktime_t" etc. But that would trigger gcc warnings. NeilBrown
Re: [PATCH v2 000/110] vfs: change inode->i_ino from unsigned long to u64
Jeff Layton wrote: > This version splits the change up to be more bisectable. It first adds a > new kino_t typedef and a new "PRIino" macro to hold the width specifier > for format strings. The conversion is done, and then everything is > changed to remove the new macro and typedef. Why remove the typedef? It might be better to keep it. David
Re: [PATCH v2 000/110] vfs: change inode->i_ino from unsigned long to u64
Jeff Layton wrote: > This version splits the change up to be more bisectable. It first adds a > new kino_t typedef and a new "PRIino" macro to hold the width specifier > for format strings. The conversion is done, and then everything is > changed to remove the new macro and typedef. Why remove the typedef? It might be better to keep it. David
Re: [PATCH v2 000/110] vfs: change inode->i_ino from unsigned long to u64
On Tue, 2026-03-03 at 10:55 +, David Howells wrote: > Jeff Layton wrote: > > > This version splits the change up to be more bisectable. It first adds a > > new kino_t typedef and a new "PRIino" macro to hold the width specifier > > for format strings. The conversion is done, and then everything is > > changed to remove the new macro and typedef. > > Why remove the typedef? It might be better to keep it. > Why? After this change, internel kernel inodes will be u64's -- full stop. I don't see what the macro or typedef will buy us at that point. -- Jeff Layton
