[PATCH] fs/efs/inode.c: use __func__ instead of function name

Jiangshan Yi posted 1 patch 3 years, 6 months ago
fs/efs/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH] fs/efs/inode.c: use __func__ instead of function name
Posted by Jiangshan Yi 3 years, 6 months ago
From: Jiangshan Yi <yijiangshan@kylinos.cn>

It is better to use __func__ instead of function name.

Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
---
 fs/efs/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/efs/inode.c b/fs/efs/inode.c
index 3ba94bb005a6..ba15c7d66adc 100644
--- a/fs/efs/inode.c
+++ b/fs/efs/inode.c
@@ -141,8 +141,8 @@ struct inode *efs_iget(struct super_block *super, unsigned long ino)
 	}
 
 	brelse(bh);
-	pr_debug("efs_iget(): inode %lu, extents %d, mode %o\n",
-		 inode->i_ino, in->numextents, inode->i_mode);
+	pr_debug("%s(): inode %lu, extents %d, mode %o\n",
+		 __func__, inode->i_ino, in->numextents, inode->i_mode);
 	switch (inode->i_mode & S_IFMT) {
 		case S_IFDIR: 
 			inode->i_op = &efs_dir_inode_operations; 
-- 
2.27.0


No virus found
		Checked by Hillstone Network AntiVirus
Re: [PATCH] fs/efs/inode.c: use __func__ instead of function name
Posted by Al Viro 3 years, 6 months ago
On Mon, Sep 19, 2022 at 10:33:14AM +0800, Jiangshan Yi wrote:
> From: Jiangshan Yi <yijiangshan@kylinos.cn>
> 
> It is better to use __func__ instead of function name.

	Why is it better?  And why is it *not* sent to (active)
maintainers of fs/erofs?  I'm not going to apply that behind their
backs and I would ask akpm to abstain from taking that one.
RE: [PATCH] fs/efs/inode.c: use __func__ instead of function name
Posted by David Laight 3 years, 6 months ago
From: Al Viro
> Sent: 20 September 2022 01:24
> 
> On Mon, Sep 19, 2022 at 10:33:14AM +0800, Jiangshan Yi wrote:
> > From: Jiangshan Yi <yijiangshan@kylinos.cn>
> >
> > It is better to use __func__ instead of function name.
> 
> 	Why is it better?  And why is it *not* sent to (active)
> maintainers of fs/erofs?  I'm not going to apply that behind their
> backs and I would ask akpm to abstain from taking that one.

It is distinctly worse.
Anyone grepping the kernel source for the message text will
fail to find it.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Re: [PATCH] fs/efs/inode.c: use __func__ instead of function name
Posted by Gao Xiang 3 years, 6 months ago
On Tue, Sep 20, 2022 at 01:24:26AM +0100, Al Viro wrote:
> On Mon, Sep 19, 2022 at 10:33:14AM +0800, Jiangshan Yi wrote:
> > From: Jiangshan Yi <yijiangshan@kylinos.cn>
> > 
> > It is better to use __func__ instead of function name.
> 
> 	Why is it better?  And why is it *not* sent to (active)
> maintainers of fs/erofs?  I'm not going to apply that behind their
> backs and I would ask akpm to abstain from taking that one.

It's efs although it also starts with letter e and ends with fs ;).
I have no idea who actually takes care of it now.

Thanks,
Gao Xiang
Re: [PATCH] fs/efs/inode.c: use __func__ instead of function name
Posted by Al Viro 3 years, 6 months ago
On Tue, Sep 20, 2022 at 08:37:13AM +0800, Gao Xiang wrote:
> On Tue, Sep 20, 2022 at 01:24:26AM +0100, Al Viro wrote:
> > On Mon, Sep 19, 2022 at 10:33:14AM +0800, Jiangshan Yi wrote:
> > > From: Jiangshan Yi <yijiangshan@kylinos.cn>
> > > 
> > > It is better to use __func__ instead of function name.
> > 
> > 	Why is it better?  And why is it *not* sent to (active)
> > maintainers of fs/erofs?  I'm not going to apply that behind their
> > backs and I would ask akpm to abstain from taking that one.
> 
> It's efs although it also starts with letter e and ends with fs ;).
> I have no idea who actually takes care of it now.

*blink*

I plead obscenely low caffeine blood levels.

And I'm still not taking that patch - IMO that kind of stuff is absolutely
pointless from anyone other than active maintainers of some code;
the rationale for using __func__ is based upon the possibility of
function getting renamed, and that's not going to happen on inactive
codebase.

IOW, *if* somebody is starting a serious work in that area - sure, might
as well throw that kind of change in, as part of the series.  Other than
that, though...  No.