Re: reiser4 plugins

[Christoph Hellwig <hch@infradead.org>]

On Tue, Jun 21, 2005 at 06:07:58PM -0700, Hans Reiser wrote:
> Christoph,
> 
> Reiser4 users love the plugin concept, and all audiences which have
> listened to a presentation on plugins have been quite positive about
> it.  Many users think it is the best thing about reiser4.  Can you
> articulate why you are opposed to plugins in more detail?  Perhaps you
> are simply not as familiar with it as the audiences I have presented
> to.  Perhaps persons on our mailing list can comment.....

You're duplicating the VFS infrastructure with your pluging system.

> In particular, what is wrong with having a plugin id associated with
> every file, storing the pluginid on disk in permanent storage in the
> stat data, and having that plugin id define the set of methods that
> implement the vfs operations associated with a particular file, rather
> than defining VFS methods only at filesystem granularity?

Hans, this only shows you didn't listen to be the last few times I
explained it to you.  There's nothing wrong with defining plug in IDs
associated with every file, and the linux file_operations, inode_operations,
etc.. are _not_ filesystem granularity but inode granularity (except in
reiser4 where you throw everything together just to add your own
de-multiplexer below).  So the only thing your plugin might need to is to
define it's own file or inode operations (in fact it might need a few
more things speaking from experience with kinda similar things, but it
certainly doesn't need to duplicate what's there)

> What is wrong with having an encryption plugin implemented in this
> manner?  What is wrong with being able to have some files implemented
> using a compression plugin, and others in the same filesystem not.

There's nothing wrong with that, although such things might be better
as a stackable filesystem.  Maybe they're not, and we'll find out once
people are prototyping these things and playing with them. But you don't
need your additional layer of abstraction for those anyway

> What is wrong with having one file in the FS use a write only plugin, in
> which the encrypion key is changed with every append in a forward but
> not backward computable manner, and in order to read a file you must
> either have a key that is stored on another computer or be reading what
> was written after the moment of cracking root?

Because root can read kernel memory this is completely useless :)
But if you want it as your private patch no one forbits you to do it,
just don't expect such security by obscurity to go into mainline.

> What we have hurts no one but us.  I have never seen an audience for one
> of my talks that thought it hurt us..... most audiences think it is
> great.  

most of your audience doesn't understand the fine points of filesystem
implementation.  they want your feature but don't care how it's implemented.
here it's the other way around - we don't care too much about what not so
important features we have but more about how sanely they're implemented.

> Let us tinker with our FS, and you tinker with yours, and so long as
> what we do does not affect your FS, let the users choose.

Now we're getting personal again, right?  My filesystems according to
MAINTAINERS are freevxfs and sysfs, but if you look at commit logs I've
done work on pretty much any filesystem in the tree, and often doing tree-wide
changes.  That's why I care about every new filesystem in the tree and not
a single one.