Re: [PATCH v2] vfs: remove externs from fs.h on functions modified by i_ino widening

[Jeff Layton]

On Mon, 2026-03-09 at 11:02 +0100, Jan Kara wrote:
> On Sat 07-03-26 14:54:31, Jeff Layton wrote:
> > Christoph says, in response to one of the patches in the i_ino widening
> > series, which changes the prototype of several functions in fs.h:
> > 
> >     "Can you please drop all these pointless externs while you're at it?"
> > 
> > Remove extern keyword from functions touched by that patch (and a few
> > that happened to be nearby). Also add missing argument names to
> > declarations that lacked them.
> > 
> > Suggested-by: Christoph Hellwig <hch@xxxxxx>
> > Reviewed-by: Christoph Hellwig <hch@xxxxxx>
> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ...
> > -extern void inode_init_once(struct inode *);
> > -extern void address_space_init_once(struct address_space *mapping);
> > -extern struct inode * igrab(struct inode *);
> > -extern ino_t iunique(struct super_block *, ino_t);
> > -extern int inode_needs_sync(struct inode *inode);
> > -extern int inode_just_drop(struct inode *inode);
> > +void inode_init_once(struct inode *inode);
> > +void address_space_init_once(struct address_space *mapping);
> > +struct inode *igrab(struct inode *inode);
> > +ino_t iunique(struct super_block *sb, ino_t max_reserved);
> 
> I've just noticed that we probably forgot to convert iunique() to use u64
> for inode numbers... Although the iunique() number allocator might prefer
> to stay within 32 bits, the interfaces should IMO still use u64 for
> consistency.
> 

I went back and forth on that one, but I left iunique() changes off
since they weren't strictly required. Most filesystems that use it
won't have more than 2^32 inodes anyway.

If they worked before with iunique() limited to 32-bit values, they
should still after this. After the i_ino widening we could certainly
change it to return a u64 though.

> Otherwise I like the changes in this patch so feel free to add:
> 
> Reviewed-by: Jan Kara <jack@xxxxxxx>
> 

Thanks!
-- 
Jeff Layton <jlayton@xxxxxxxxxx>