Re: reiser4 plugins

[Hans Reiser]

Think of reiser4 as being designed to be 90% library routines, and 10%
program.  Now, can these libraries be used by other filesystems?  Why
yes, some can.  How many of them should be used by other filesystems? 

Reality:  few people are going to rewrite their existing filesytems to
mostly use our code.  However, people writing new filesystems, if we
have done our job right, will decide that our code is the easiest code
base to use for implementing whatever differentiates them while avoiding
reinventing what they don't seek to be better at.  Detail: Regarding our
allocation and balance and compress and encrypt at flush time code,
unless your filesystem is also based on balanced trees it might be the
least reusable code in the filesystem.  It is the hardest code in the
filesystem, because the algorithms we implemented were simply hard. 
Number one task for me, after we go in and I can stop dealing with
prerequisites to inclusion, is to review the vm interaction from
beginning to end one more time (and kill the emergency flush code).

Good part: if you want to implement new filesystem semantics, our
storage layer is more suitable for your innovating on top of than any
other.  Less work to code it, more functionality and flexibility,
plugins are great for hacking on top of.  The storage layer is very very
high performance, and if semantics are your focus, using our storage
layer is likely to be a good choice because it is well abstracted and
works without understanding what it works on.  For example, you can
invent new items for the tree to balance (e.g. new directory entry
formats), and all you have to do is write an item handler for the item
and you don't have to touch the balancing code.

In general, if a new filesystem can do some narrow aspect better than
our existing library routine, it should do its aspect using its
innovative new code, and where it is not trying to be better than us, it
can reuse our code more easily than any alternative.   Many people who
would write a new filesystem from scratch, can, if they use our code
base, accomplish their objectives with just writing some new plugins and
contributing them to the collection.  Others can define a new filesystem
to consist of a particular configuration of plugins and glue that are
what you get when you mount fubarfs.  We would be happy to accomodate
that by creating subdirectories for different flavorings of reiser4 to
live in.

Because our code is 90% library routines (aka plugins), eliminating the
plugin layer is like eliminating main() in a user space program.

Hans

David Masover wrote:

> Actually, I'll have to go back on this a bit.  There are different kinds
> of plugins, and I'm not sure exactly which people want in the VFS.  This
> may be because nobody's said that, though.
>
> Still, while plugins may not depend on Reiser, Reiser depends on 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/