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

[Jan Kara]

On Mon 09-03-26 07:53:51, Jeff Layton wrote:
> 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.

Yes, it won't change anything wrt functionality. I just think that if we go
for "ino_t is the userspace API type and kernel-internal inode numbers
(i.e.  what gets stored in inode->i_ino) are passed as u64", then this
place should logically have u64...

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR