Maciej Sołtysiak wrote:
I Understand. This is good news. Hm, do you think that reiser4's pluggability
is enough to have this single kernel tree (fs/reiser4) for a longer period
away with the "future vision" and other "future *" stuff you've written
about ? eg. I remember reading about very granular security ACLs like
restricting a certain line in a file (like /etc/passwd)
I think the granular security ACLs were always intended to be a v4 thing
(with plugins). I believe the Future Vision stuff is about even more
namespace unification. I seem to remember v5 was semantic changes and
v6 was a semi-distributed FS, but I could have that backwards...
Anyway, there are definitely plans for things which are non-trivially
beyond the plugin capabilities of Reiser4, though they will almost
certainly use Reiser4 as a starting point.
There's another note to kernel developers -- if Reiser5, 6, and 7 are
implemented as suites of plugins on top of Reiser4, then the Reiser4
code will be maintained for a very long time. Kind of like ext2 vs
ext3, only moreso -- a Reiser5 FS may well be a Reiser4 FS mounted with
additional mount options.
There is definitely a lot that can be done to move Reiser4 (as it is
today) closer to the Reiser4 whitepaper on the homepage. ACLs are one
thing, files as a directory are another. The idea of v4 is to do away
with many cases where a separate namespace is created for no good reason
-- for instance, where is the data in an id3 tag? It's inside an mp3
file, and you can only get to it with tools written for id3 tags of mp3
files. The Reiser4 concept is to allow things like that to exist, but
not require programs to know about libid3 or whatever. Want to know
what the artist of a particular file is?
foo.mp3/.../id3/artist
Or maybe a more generic way:
foo.mp3/.../song-info/artist
That way, you could have tools which don't even have to know if the file
has an id3 tag, or something entirely new, or if the metadata is being
stored outside the main file. It'd be entirely possible to allow that
file to be treated as a separate file entirely by the plugin, rather
than something derived from foo.mp3.
The advantages don't seem immediately obvious until you consider that
the program which does this doesn't have to even know that it's dealing
with song metadata. Consider some of the one-line shell scripts possible:
# Change the artist name for all songs in the directory:
for i in *; do echo 'Jimi Hendrix' > foo.mp3/.../song-info/artist; done
# Make a playlist of all files by Hendrix, mp3 or otherwise:
for i in `find`; do
if [ `cat "$i/.../song-info/artist"` == 'Jimi Hendrix' ]; then
echo "../$i" >> playlists/hendrix.m3u;
fi;
done
# Copy all files needed by said playlist to a USB device:
cp playlist/hendrix.m3u/.../files/* /mnt/usb
cp playlist/hendrix.m3u /mnt/usb
I'm sure others can think of much more interesting examples.
All of that is planned for v4, eventually. It's very pluggable.
Well, I think it is. I don't work here...
