2005-01-08 19:31:03

by Al Viro

[permalink] [raw]
Subject: Re: Export get_sb_pseudo()?

On Sat, Jan 08, 2005 at 10:40:10AM -0800, Roland Dreier wrote:
> I'm planning on implementing some modular driver code and I think it
> makes sense to have a non-mountable pseudofs. Especially with the
> recent MVFS controversy, it seems prudent to find out whether this
> usage would merit exporting get_sb_pseudo(), so I'll describe my
> current plans below.

No objections; it certainly falls under "general-purpose library
helper". Moreover, in this case I _insist_ on use of normal
export; it is a convenience helper that
a) can be trivially reimplemented by anyone who cares; any
number of filesystems is open-coding far more than that in their
->get_sb(), so there's nothing to protect here.
b) can be trivially simulated by simple_fill_super() followed
by a bit of tweaking the result.
c) does not shove any pitchforks into the kernel guts - resulting
superblock does not require any special treatment.

So feel free to go ahead and export it; as the matter of fact, if you
don't do it, I will. And that puppy is my code except for one line
from Andi Kleen (sb->s_time_gran = 1; ;-). Since we both are OK with
full export (I'd just asked him), anybody who has objections to that
can take 'em and shove 'em...


2005-01-08 19:42:36

by Christoph Hellwig

[permalink] [raw]
Subject: Re: Export get_sb_pseudo()?

On Sat, Jan 08, 2005 at 07:31:01PM +0000, Al Viro wrote:
> On Sat, Jan 08, 2005 at 10:40:10AM -0800, Roland Dreier wrote:
> > I'm planning on implementing some modular driver code and I think it
> > makes sense to have a non-mountable pseudofs. Especially with the
> > recent MVFS controversy, it seems prudent to find out whether this
> > usage would merit exporting get_sb_pseudo(), so I'll describe my
> > current plans below.
>
> No objections; it certainly falls under "general-purpose library
> helper". Moreover, in this case I _insist_ on use of normal
> export; it is a convenience helper that
> a) can be trivially reimplemented by anyone who cares; any
> number of filesystems is open-coding far more than that in their
> ->get_sb(), so there's nothing to protect here.
> b) can be trivially simulated by simple_fill_super() followed
> by a bit of tweaking the result.
> c) does not shove any pitchforks into the kernel guts - resulting
> superblock does not require any special treatment.

Agreed.

2005-01-08 20:33:53

by Roland Dreier

[permalink] [raw]
Subject: [PATCH] Export get_sb_pseudo()

Al> So feel free to go ahead and export it; as the matter of fact,
Al> if you don't do it, I will.

Thanks, here's the trivial patch.


Export get_sb_pseudo() so that modules can create unmountable
pseudo-filesystems cleanly.

Signed-off-by: Roland Dreier <[email protected]>

Index: linux-bk/fs/libfs.c
===================================================================
--- linux-bk.orig/fs/libfs.c 2004-12-29 22:05:29.000000000 -0800
+++ linux-bk/fs/libfs.c 2005-01-06 13:13:26.254907840 -0800
@@ -522,6 +522,7 @@
EXPORT_SYMBOL(dcache_dir_open);
EXPORT_SYMBOL(dcache_readdir);
EXPORT_SYMBOL(generic_read_dir);
+EXPORT_SYMBOL(get_sb_pseudo);
EXPORT_SYMBOL(simple_commit_write);
EXPORT_SYMBOL(simple_dir_inode_operations);
EXPORT_SYMBOL(simple_dir_operations);