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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
