On 2024/3/7 16:46, Al Viro wrote:
On Thu, Mar 07, 2024 at 07:21:12AM +0000, Al Viro wrote:
On Thu, Mar 07, 2024 at 03:06:49PM +0800, Baokun Li wrote:
+int erofs_anon_register_fs(void)
+{
+       return register_filesystem(&erofs_anon_fs_type);
+}
What for?  The only thing it gives you is an ability to look it up by
name.  Which is completely pointless, IMO,
The helper function here is to avoid extern erofs_anon_fs_type(), because
we define it in fscache.c, but also use it in super.c. Moreover, we don't
need
to register it when CONFIG_EROFS_FS_ONDEMAND is not enabled, so we
You don't need to register it at all.

The one and only effect of register_filesystem() is making file_system_type
instance visible to get_fs_type() (and making it show up in /proc/filesystems).

That's it.  If you want to have it looked up by name (e.g. for userland
mounts), you need to register.  If not, you do not need to do that.

Note that kern_mount() take a pointer to struct file_system_type,
not its (string) name.  So all you get from registration is an extra line
in /proc/filesystems.  What's the point?
PS: at one point I considered renaming it to something that would sound
less vague, but the best variant I'd been able to come up with was
"publish_filesystem()", which is not much better and has an extra problem -
how do you describe the reverse of that?  "withdraw_filesystem()"?
Decided that it wasn't worth the amount of noise and headache...
I feel the emphasis on "fs_name" rather than "filesystem" is less
likely to be misunderstood. What do you think about renaming
to add_fs_name/remove_fs_name?

--
With Best Regards,
Baokun Li
.

Reply via email to