There is a number of pseudo file systems in the kernel
that are basically copies of debugfs, all implementing the
same boilerplate code, just with different bugs.

This adds yet another copy to the kernel in the libfs directory,
with generalized helpers that can be used by any of them.

The most interesting function here is the new "struct dentry *
simple_register_filesystem(struct simple_fs_type *type)", which
returns the root directory of a new file system that can then
be passed to simple_create_file() and similar functions as a
parent.

Signed-off-by: Arnd Bergman <arnd@arndb.de>
Index: linux-2.6/fs/libfs.c
===================================================================
--- linux-2.6.orig/fs/libfs.c
+++ linux-2.6/fs/libfs.c
@@ -263,11 +263,6 @@ int simple_link(struct dentry *old_dentr
 	return 0;
 }
 
-static inline int simple_positive(struct dentry *dentry)
-{
-	return dentry->d_inode && !d_unhashed(dentry);
-}
-
 int simple_empty(struct dentry *dentry)
 {
 	struct dentry *child;
@@ -409,109 +404,6 @@ int simple_write_end(struct file *file, 
 	return copied;
 }
 
-/*
- * the inodes created here are not hashed. If you use iunique to generate
- * unique inode values later for this filesystem, then you must take care
- * to pass it an appropriate max_reserved value to avoid collisions.
- */
-int simple_fill_super(struct super_block *s, int magic, struct tree_descr *files)
-{
-	struct inode *inode;
-	struct dentry *root;
-	struct dentry *dentry;
-	int i;
-
-	s->s_blocksize = PAGE_CACHE_SIZE;
-	s->s_blocksize_bits = PAGE_CACHE_SHIFT;
-	s->s_magic = magic;
-	s->s_op = &simple_super_operations;
-	s->s_time_gran = 1;
-
-	inode = new_inode(s);
-	if (!inode)
-		return -ENOMEM;
-	/*
-	 * because the root inode is 1, the files array must not contain an
-	 * entry at index 1
-	 */
-	inode->i_ino = 1;
-	inode->i_mode = S_IFDIR | 0755;
-	inode->i_uid = inode->i_gid = 0;
-	inode->i_blocks = 0;
-	inode->i_atime = inode->i_mtime = inode->i_ctime = ...
[ message continues ]

Don't mix "split the file" with "add new stuff", please.  And frankly,
I'm not convinced that embedding file_system_type into another struct
is a good idea.
-

[ message continues ]

Right, that has been one of the areas I've been thinking about
myself without coming to a good solution. One alternative I
thought about is to have the news members as part of file_system_type
itself, but that would cost a bit of memory for every single 
file system, and might lead to unintended misuse of these members
by non-simple file systems.

Do you think it would be better to dynamically allocate the
file_system_type and have a pointer in struct simple_fs_type to
it?

	Arnd <><
-

[ message continues ]