Re: silent semantic changes with reiser4

[Hans Reiser]

Andrew Morton wrote:

> Hans Reiser <reiser@xxxxxxxxxxx> wrote:
>  
>
> > >To get us started on this route it would really help me (and, probably,
> > >others) if you could describe what these API extensions are in a very
> > >simple way, without referring to incomprehehsible web pages,
> > >
> > what is not comprehensible....?
> >    
>
> Pretty much anything at www.namesys.com.  The amount of time which is
> needed to extract the technical info which one is looking for vastly
> exceeds a gnat-like attention span.
>
> As a starting point, please prepare a bullet-point list of
> userspace-visible changes which the filesystem introduces, or is planned to
> introduce.
>
> And describe the "plugin" system.  Why does the filesystem need such a
> thing (other filesystems get their features via `patch -p1')?
>  
It takes 6 months or more to become competent to change a usual 
filesystem.  Creating a new reiser4 plugin is a weekend programmer fun 
hack to do.  Weekend programmers matter, because they tend to have 
clever ideas based on understanding a need they have.   How many people 
can easily add new features to ext3 or reiserfs V3?  Very few. 

What happens if you need a disk format change?

Well, in V4, you can easily compose a plugin from plugin methods of 
other plugins, write a little piece of code with the one thing you want 
different, and add it in.  Disk format changes, no big deal, add a new 
disk format plugin, or a new item plugin, or a new node plugin, etc., 
and you got your new format.

There is a huge difference between code that is designed for reuse, and 
code that is not.  That is the difference between V3 and V4.  We were 
looking at our V3 balancing code, and it special cased each different 
kind of item (an item is a piece of something, which the balancing code 
chops objects into as it squeezes them into nodes).  It looked like the 
complexity of the balancing code was going to be N squared, where N was 
the number of different kinds of items.

So, we created item handlers, and wrote balancing code that could slice 
and dice and merge any item that implemented all of the operations 
required of an item handler.  From there it grew, and we made everything 
pluggable.

Adding features to the new code is far less than the time cost of adding 
features to the old code.  I've seen Nikita complain that something 
would take 6 weeks to do (changing key assignment algorithms), and then 
it takes him 3 afternoons, and it was because of the plugins, because 
when we did something similar in V3 it took 3 man months.

> And what are the licensing implications of plugins?  Are they derived
> works?  
Yes.

Hans
-
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/