lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: silent semantic changes with reiser4
Andrew Morton wrote:

>Hans Reiser <reiser@namesys.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site