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

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

    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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.023 / U:1.208 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site