On 2024/8/29 8:56, Damien Le Moal wrote:
On 8/28/24 21:01, Hongbo Li wrote:
The sb->s_magic holds the file system magic, we can use
this to avoid use file system magic macro directly.
Signed-off-by: Hongbo Li <lihongbo22@xxxxxxxxxx>
---
fs/zonefs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/zonefs/super.c b/fs/zonefs/super.c
index faf1eb87895d..1ecbf19ccc58 100644
--- a/fs/zonefs/super.c
+++ b/fs/zonefs/super.c
@@ -444,7 +444,7 @@ static int zonefs_statfs(struct dentry *dentry, struct kstatfs *buf)
struct zonefs_sb_info *sbi = ZONEFS_SB(sb);
enum zonefs_ztype t;
- buf->f_type = ZONEFS_MAGIC;
+ buf->f_type = sb->s_magic;
I fail to see the benefits of this change. "we can do it differently" is not
really an argument in itself without clear benefits. And in this case, that
function will have an additional sb pointer dereference, so be slower (not that
it matters though since this is not the hot path).
Just avoid using the macro directly. No other benefits.
This kind of macro definition is like a magic number; once it changes,
it will affect a large amount of code.
It's just my personal opinion. 😉
Thanks,
Hongbo
See other file systems (e.g. xfs_fs_statfs), many do the same thing and use
their MAGIC macro for this field.
buf->f_bsize = sb->s_blocksize;
buf->f_namelen = ZONEFS_NAME_MAX;
