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 - from userspace.

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 window.

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 FUSE-like interface.


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