Messages in this thread | | | Date | Fri, 24 Jun 2005 02:35:10 -0700 (PDT) | From | Timothy Webster <> | Subject | Re: reiser4 plugins |
| |
--- Lincoln Dale <ltd@cisco.com> wrote: snip
> > 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
-Tim
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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/
| |