Re: silent semantic changes with reiser4

[Horst von Brand]

Lee Revell <rlrevell@xxxxxxxxxxx> said:
> To: Pavel Machek <pavel@xxxxxx>
> Cc: Spam <spam@xxxxxxxxxxxx>, Horst von Brand <vonbrand@xxxxxxxxxxxx>,
>         Jamie Lokier <jamie@xxxxxxxxxxxxx>, David Masover <ninja@xxxxxxxxxxxx>,
>         Chris Wedgwood <cw@xxxxxxxx>, viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,
>         Linus Torvalds <torvalds@xxxxxxxx>, Christoph Hellwig <hch@xxxxxx>,
>         Hans Reiser <reiser@xxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx,
>         linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>,
>         Alexander Lyamin aka FLX <flx@xxxxxxxxxxx>,
>         ReiserFS List <reiserfs-list@xxxxxxxxxxx>
> X-Mailer: Ximian Evolution 1.4.6 
> Date: Thu, 02 Sep 2004 16:01:17 -0400
> 
> On Thu, 2004-09-02 at 15:49, Pavel Machek wrote:

[...]

> > You really need archive support in find. At the very least you need
> > option "enter archives" vs. "do not enter archives". Entering archives
> > automagically is seriously wrong.

I have used find(1) for quite some time now, and have never (or very
rarely) missed this.

> But is it efficient to make every application that reads files have to
> know how to get inside a tar file, just to read its contents?

Totally ridiculous, especially if you factor in .gz, .bz2, .zip, .a,
.whatever.new.format.they.come.up.with.tomorrow. But then again, this would
presumably reside in a (shared) library, so it isn't so bad...

>                                                                That
> seems like a massive duplication of effort.

Right. tar, gzip, bunzip, et al are already around.

>                                              Better to have the contents
> accessible via a separate stream, in the same namespace.  Fix it once in
> the kernel vs. fix it in umpteen apps.

Dead wrong. It is better to fix it in userspace (via a library, if
required; could call random unpacking etc programs at will, even be
configured on a user-by-user basis through ~/.wacky-file-handling or
environment) than force this junk into the kernel. Kernel code is _always_
resident, extremely security critical, and hard to get right. Besides, not
everybody will want to carry this around, and so it will forever stay a
"weird Linux kernel configuration only" feature, i.e., useless in practice.

> The key point here is that the expressive power of the system is greatly
> reduced by having a fragmented namespace.  Of course there are any
> number of ways for an app to find out what is in a tar file, but
> exporting all of that information in a unified namespace is nontrivial
> and much more interesting.

I don't see how it is "nontrivial": "tar tf some.tar" is quite enough to
find out what is inside, in a customary format.

Placing random junk in the kernel doesn't magically make it fast, right, or
useful. Quite a lot of work is required for that, much more than for
getting the same in userland.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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/