Re: silent semantic changes with reiser4

From: Yury Umanets
Date: Sat Aug 28 2004 - 06:09:20 EST


Andrea Arcangeli wrote:

On Thu, Aug 26, 2004 at 01:35:01AM -0700, Hans Reiser wrote:


Reiser4 plugins are not for end users to download from amazon.com, they are for weekend hackers to send me a cool plugin for me to review, assign a plugin id to, and send to Linus in the next release. Sometimes


then what's the difference in having the plugin fixed in stone into
reiserfs? That's my whole point. Get the patch from the weekend hacker,
check it, send the patch to Linus to add the new feature to reiser4,
just call it "feature" not plugin. That's how it works normally for
everything. Many fs have many features, many of them optional. you
wouldn't need to build any hook infrastructure either that way. Hooks
would be needed if this wasn't open source me thinks. Or if you want
people to fetch the module from amazon without your review.

Another reason I could see the modularization/hooking useful is if those
feature would take lots of kernel space, but this sure isn't the case
for reiserfs, infact having modules would waste _more_ ram due the half
wasted page allocation for the module text. The only single reason we
use modules is to avoid wasting tons of ram by loading every possible
device driver on earth, it's not that we use modules because they're
more flexible, if something they're more fragile. I never use modules in
my test kernel just to go fast (because I self compile them). The last
good thing of the modules is during development you don't need to reboot
the machine to test a kernel change in a driver, but you don't need that
with reiserfs since you can make the fs itself a module (just change the
name of the fs, AFIK you do that all the time already).


There lots of good things about plugins as they are in reiser4. And
probably the best one (as for me) is that, reiser4 core code (quite
complex thing) does not need to be changed after adding new plugins
(read new features).

It is written once and provides some basic functionality (balancing,
atoms, etc.), which works well with all kinds of plugins if they
implement required functions from plugin interface.

As for me, this looks like Linux's VFS. Sure, if I want to add some very
new filesystem with features which were not foreseen, and VFS does not
provide needed interface, it will need some changes. But in simple case,
when I just want to develop once more disk filesystem, which say will be
different from another disk filesystem in only that respect it manages
its metadata in different manner and aims to achieve better performance
this way. In this case I will not need to chnage VFS at all. The same
about reiser4 core and new plugins.

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






--
umka



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