[lkml]   [2005]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: reiser4 plugins

--- Lincoln Dale <> wrote:

> Nikita basically said as much in Message-ID:
> <17081.30107.751071.983835@gargle.gargle.HOWL>
> earlier in this thread:
> "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.
> 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."

What reiserfs4 brings is file based plugins. Which is
extremely useful and powerful. I don't want to see
this go away.

I think it is the task of the linux community to
generalize the vfs layer and not lock out reiserfs4
until that is done. reiserfs4 wants to keep a plugin
id for each and every file. An additional filesystem
layer is the traditional solution to achieve advanced
features, but not an optimal solution in my opinion.
Yes gnome, kde and perhaps cifs do it. But if instead
they used file plugins a lot more could be shared.

Blush, I am not a file system expert


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-06-24 11:43    [W:0.342 / U:2.596 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site