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

[Jan Kara]

On Mon 02-03-26 15:23:45, Jeff Layton wrote:
> Introduce a kino_t typedef and PRIino format macro to enable a
> bisect-clean transition of i_ino from unsigned long to u64.
> 
> kino_t is initially defined as unsigned long (matching the original
> i_ino type), and PRIino is "l" (the format length modifier for
> unsigned long). A later patch will change these to u64 and "ll"
> respectively once all format strings have been updated to use PRIino.
> 
> The PRIino macro is a length modifier, not a complete format specifier.
> It is used as: "%" PRIino "u" for decimal, "%" PRIino "x" for hex, etc.
> This follows the pattern used by userspace PRIu64/PRIx64 macros.
> 
> Format strings using i_ino should be updated to use PRIino instead of
> a hard-coded length modifier to ensure warning-free compilation on
> both 32-bit and 64-bit architectures throughout the transition.
> 
> Signed-off-by: Jeff Layton <jlayton at kernel.org>

Yeah, as a temporary solution for bisectability this looks fine to me. Feel
free to add:

Reviewed-by: Jan Kara <jack at suse.cz>

								Honza

> ---
>  include/linux/fs.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8b3dd145b25ec12b00ac1df17a952d9116b88047..e38bc5ece1f360d679a8f30b8171292f7a65c218 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -758,6 +758,9 @@ struct inode_state_flags {
>  	enum inode_state_flags_enum __state;
>  };
>  
> +typedef unsigned long	kino_t;
> +#define PRIino		"l"
> +
>  /*
>   * Keep mostly read-only and often accessed (especially for
>   * the RCU path lookup and 'stat' data) fields at the beginning
> @@ -783,7 +786,7 @@ struct inode {
>  #endif
>  
>  	/* Stat data, not accessed from path walking */
> -	unsigned long		i_ino;
> +	kino_t			i_ino;
>  	/*
>  	 * Filesystems may only read i_nlink directly.  They shall use the
>  	 * following functions for modification:
> 
> -- 
> 2.53.0
> 
-- 
Jan Kara <jack at suse.com>
SUSE Labs, CR