Re: "Why Reuser 4 still is not in" doc
From: Lexington Luthor
Date: Mon Jul 17 2006 - 12:37:56 EST
Jan Engelhardt wrote:
Yes, it changes the semantics. Suddenly you can "cd linux-2.6.17.tar.bz2".
But what will stat() return? S_IFDIR? S_IFREG? S_IFANY? A .tar parser in
kernelspace is almost never the right thing. And then a cpio parser,
because that's what initramfs'es are made of. Not to forget .zip, because
that's omnipresent. Oh of course we'd also need bzip2 and gzip decoder.
BASE64 and UU anyone?
Is there any particular reason that the parsers need to be in
kernel-space. The reiser4 plugins seem like an ideal counterpart to
FUSE. Imagine being able to automatically FUSE-mount a tar file as a
filesystem when you cd into it. stat() need not return S_IFDIR since
everything is a directory anyway (only normal directories need S_IFDIR,
just like currently). When you cd into a tar file, a FUSE-fs kicks in
and provides access to the tar file as a normal filesystem inside it -
I wish you a lot of fun with users in LDAP or other exotic storage methods.
By making Everything possible through echo, you are violating the unix
philosophy that one tool should do one thing (though echo does just that).
And in this case, echo would be chown, chmod, tar, bzip2 all at once. This
sounds familiar, I think I have seen this with explorer.exe (and its
uncountable DLLs), which lets you change everything within the same
And why can meta-data not be accessed as files? To me, a lowly userspace
developer, it seems even more inline with the UNIX way of things. bzip2
can be in userspace while still providing data to kernel space via a
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/