Re: (reiserfs) Re: Summary of how linux can best avoid the need for streams

Raul Miller (moth@magenta.com)
Thu, 1 Jul 1999 10:26:43 -0400


Albert D. Cahalan <acahalan@cs.uml.edu> wrote:
> Why is it fine just this once? You wanted to manipulate individual
> components with normal tools, but clearly you can't. You need special
> tools to insert and extract data. If anything, this is _worse_ than
> a multi-forked file. You will need a separate tool for each app.

No. You're right that the apps need a well designed interface
to work with. However, that interface needs to be a C library.
Apps on linux never get to talk directly to the kernel -- they
talk to C libraries which translate things appropriately for
the kernel.

And, as people have stated (repeatedly): for portability you need to
have a portable implementation of the library. It's fine to have an
optimized version that talks to some special linux feature, but that
*must* be recognized as an optimization.

Finally, I've seen people object to the use of directories because apps
might create names with /../ in them. However, this is trivial to work
around by altering the name from the app before passing it to the kernel
(use a prefix character, or some out-of-band escape character, or any
of a variety of other schemes).

[I've also seen objections of the form: what if some random app mucks
with the internal structure of a document-represented-as-a-directory.
But again, this is trivial to deal with: mark the document components
read-only. Your "Real users" coming through your high level interface
(that supports this document structure) aren't likely to even notice, but
if they do somehow get to the command line or some alternative interface
they'll still get permission denied if they try to mutilate a document.]

-- 
Raul

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/