Re: Export get_sb_pseudo()?

Re: Export get_sb_pseudo()?

[Al Viro]

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...

Re: Export get_sb_pseudo()?

[Christoph Hellwig]

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.

[PATCH] Export get_sb_pseudo()

[Roland Dreier]

    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 <roland@topspin.com>

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);