lkml.org 
[lkml]   [2006]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Reiser4 und LZO compression
    PFC wrote:
    >
    >
    > Would it be, by any chance, possible to tweak the thing so that
    > reiserfs plugins become kernel modules, so that the reiserfs core can be
    > put in the kernel without the plugins slowing down its acceptance ?

    I don't see what this has to do with cryptoapi plugins -- those are not
    related to Reiser plugins.

    As for the plugins slowing down acceptance, it's actually the concept of
    plugins and the plugin API -- in other words, it's the fact that Reiser4
    supports plugins -- that is slowing it down, if anything about plugins
    is still an issue at all.

    Making them modules would make it worse. Last I saw, Linus doesn't
    particularly like the idea of plugins because of a few misconceptions,
    like the possibility of proprietary (possibly GPL-violating) plugins
    distributed as modules -- basically, something like what nVidia and ATI
    do with their video drivers.

    As it is, a good argument in favor of plugins is that this kind of thing
    isn't possible -- we often put "plugins" in quotes because really, it's
    just a nice abstraction layer. They aren't any more plugins than
    iptables modules or cryptoapi plugins are. If anything, they're less,
    because they must be compiled into Reiser4, which means either one huge
    monolithic Reiser4 module (including all plugins), or everything
    compiled into the kernel image.

    > (and updating plugins without rebooting would be a nice extra)

    It probably wouldn't be as nice as you think. Remember, if you're using
    a certain plugin in your root FS, it's part of the FS, so I don't think
    you'd be able to remove that plugin any more than you're able to remove
    reiser4.ko if that's your root FS. You'd have to unmount every FS that
    uses that plugin.

    At this point, you don't really gain much -- if you unmount every last
    Reiser4 filesystem, you can then remove reiser4.ko, recompile it, and
    load a new one with different plugins enabled.

    Also, these things would typically be part of a kernel update anyway,
    meaning a reboot anyway.

    But suppose you could remove a plugin, what then? What would that mean?
    Suppose half your files are compressed and you remove cryptocompress
    -- are those files uncompressed when the plugin goes away? Probably
    not. The only smart way to handle this that I can think of is to make
    those files unavailable, which is probably not what you want -- how do
    you update cryptocompress when the new reiser4_cryptocompress.ko is
    itself compressed?

    That may be an acceptable solution for some plugins, but you'd have to
    be extremely careful which ones you remove. The only safe way I can
    imagine doing this may not be possible, and if it is, it's extremely
    hackish -- load the plugin under another module name, so
    r4_cryptocompress would be r4_cryptocompress_init -- have the module,
    once loaded, do an atomic switch from the old one to the new one,
    effectively in-place.

    But that kind of solution is something I've never seen attempted, and
    only really heard of in strange environments like Erlang. It would
    probably require much more engineering than the Reiser team can handle
    right now, especially with their hands full with inclusion.

    >>> The patch below is so-called reiser4 LZO compression plugin as extracted
    >>> from 2.6.18-rc4-mm3.
    >>>
    >>> I think it is an unauditable piece of shit and thus should not enter
    >>> mainline.
    >>
    >> Like lib/inflate.c (and this new code should arguably be in lib/).
    >>
    >> The problem is that if we clean this up, we've diverged very much from
    >> the
    >> upstream implementation. So taking in fixes and features from upstream
    >> becomes harder and more error-prone.
    >>
    >> I'd suspect that the maturity of these utilities is such that we could
    >> afford to turn them into kernel code in the expectation that any future
    >> changes will be small. But it's not a completely simple call.
    >>
    >> (iirc the inflate code had a buffer overrun a while back, which was found
    >> and fixed in the upstream version).
    >>
    >>
    >
    >

    -
    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: 2006-08-29 19:41    [W:2.555 / U:0.296 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site