linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] what's the point of register_filesystem() in drivers/dax/super.c?
@ 2019-03-16 16:23 Al Viro
  2019-03-16 20:10 ` Dan Williams
  0 siblings, 1 reply; 4+ messages in thread
From: Al Viro @ 2019-03-16 16:23 UTC (permalink / raw)
  To: Dan Williams; +Cc: linux-fsdevel

	It's not user-mountable, kern_mount() doesn't care about
looking it up by name, so the only effect of having it registered
is having it visible in /proc/filesystems.

	Do you need that for anything?  Because I would rather
avoid more of that voodoo...

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] what's the point of register_filesystem() in drivers/dax/super.c?
  2019-03-16 16:23 [RFC] what's the point of register_filesystem() in drivers/dax/super.c? Al Viro
@ 2019-03-16 20:10 ` Dan Williams
  2019-03-16 20:26   ` Al Viro
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Williams @ 2019-03-16 20:10 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel

On Sat, Mar 16, 2019 at 9:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         It's not user-mountable, kern_mount() doesn't care about
> looking it up by name, so the only effect of having it registered
> is having it visible in /proc/filesystems.
>
>         Do you need that for anything?  Because I would rather
> avoid more of that voodoo...

It can die. It was mindless copy/paste from fs/blockdev.c and the
"bdev" fs. The device-dax unit tests pass just fine with it removed.
I'll send a formal patch with the following:

diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index ccb22d8db3a2..3d6a9e61e358 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -615,10 +615,6 @@ static int dax_fs_init(void)
        if (!dax_cache)
                return -ENOMEM;

-       rc = register_filesystem(&dax_fs_type);
-       if (rc)
-               goto err_register_fs;
-
        dax_mnt = kern_mount(&dax_fs_type);
        if (IS_ERR(dax_mnt)) {
                rc = PTR_ERR(dax_mnt);
@@ -629,8 +625,6 @@ static int dax_fs_init(void)
        return 0;

  err_mount:
-       unregister_filesystem(&dax_fs_type);
- err_register_fs:
        kmem_cache_destroy(dax_cache);

        return rc;
@@ -639,7 +633,6 @@ static int dax_fs_init(void)
 static void dax_fs_exit(void)
 {
        kern_unmount(dax_mnt);
-       unregister_filesystem(&dax_fs_type);
        kmem_cache_destroy(dax_cache);
 }

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [RFC] what's the point of register_filesystem() in drivers/dax/super.c?
  2019-03-16 20:10 ` Dan Williams
@ 2019-03-16 20:26   ` Al Viro
  2019-03-17 17:56     ` Dan Williams
  0 siblings, 1 reply; 4+ messages in thread
From: Al Viro @ 2019-03-16 20:26 UTC (permalink / raw)
  To: Dan Williams; +Cc: linux-fsdevel

On Sat, Mar 16, 2019 at 01:10:26PM -0700, Dan Williams wrote:
> On Sat, Mar 16, 2019 at 9:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> >         It's not user-mountable, kern_mount() doesn't care about
> > looking it up by name, so the only effect of having it registered
> > is having it visible in /proc/filesystems.
> >
> >         Do you need that for anything?  Because I would rather
> > avoid more of that voodoo...
> 
> It can die. It was mindless copy/paste from fs/blockdev.c and the
> "bdev" fs. The device-dax unit tests pass just fine with it removed.
> I'll send a formal patch with the following:

Acked-by: Al Viro <viro@zeniv.linux.org.uk>

Do you prefer it in your tree, or would you rather have it go through
vfs.git?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] what's the point of register_filesystem() in drivers/dax/super.c?
  2019-03-16 20:26   ` Al Viro
@ 2019-03-17 17:56     ` Dan Williams
  0 siblings, 0 replies; 4+ messages in thread
From: Dan Williams @ 2019-03-17 17:56 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel

On Sat, Mar 16, 2019 at 1:26 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Sat, Mar 16, 2019 at 01:10:26PM -0700, Dan Williams wrote:
> > On Sat, Mar 16, 2019 at 9:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > >         It's not user-mountable, kern_mount() doesn't care about
> > > looking it up by name, so the only effect of having it registered
> > > is having it visible in /proc/filesystems.
> > >
> > >         Do you need that for anything?  Because I would rather
> > > avoid more of that voodoo...
> >
> > It can die. It was mindless copy/paste from fs/blockdev.c and the
> > "bdev" fs. The device-dax unit tests pass just fine with it removed.
> > I'll send a formal patch with the following:
>
> Acked-by: Al Viro <viro@zeniv.linux.org.uk>
>
> Do you prefer it in your tree, or would you rather have it go through
> vfs.git?

vfs.git is fine. Patch inbound.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-03-17 17:56 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-16 16:23 [RFC] what's the point of register_filesystem() in drivers/dax/super.c? Al Viro
2019-03-16 20:10 ` Dan Williams
2019-03-16 20:26   ` Al Viro
2019-03-17 17:56     ` Dan Williams

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).