Re: reiser4 plugins

[Vladimir Saveliev <vs@namesys.com>]

Hello

On Wed, 2005-06-22 at 18:28, Nikita Danilov wrote:
> David Masover writes:
> 
> [...]
> 
>  > 
>  > Maintainability is like optimization.  The maintainability of a
>  > non-working program is irrelevant.  You'd be right if we already had
>  > plugins-in-the-VFS.  We don't.  The most maintainable solution for
>  > plugins-in-the-FS that actually exists is Reiser4, exactly as it is now
>  > - -- because it is the _only_ one that actually exists right now.
> 
> But it is not so. There _are_ plugins-in-the-VFS. VFS operates on opaque
> objects (inodes, dentries, file system types) through interfaces:
> {inode,address_space,dentry,sb,etc.}_operations. Every file system
> back-end if free to implement whatever number of these interfaces. And
> the do this already: check the sources; even ext2 does this: e.g.,
> ext2_fast_symlink_inode_operations and ext2_symlink_inode_operations.
> 

imho, this is something different. Ext2 decides itself how to manage a
symlink depending on length of string the symlink is to store.
Reiser4 plugins are to allow a user to define himself which operations
file is to be managed with.

> This is exactly what upper level reiser4 plugins are for.

> I guess that one of Christoph Hellwig's complaints is that reiser4
> introduces another layer of abstraction to implement something that
> already exists.
> 

I do not think that it exists already.
You can have standart type of files and that is all.

Linux filesystem is not supposed to provide anything but plain
regular/directory/symlinks/sockets/block device/char device/fifo files.

Existing file API does not allow create anything but that.
Merging reiser4 with object plugins would make it necessary to modify
VFS layer so that files of arbitrary types could be created.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/