lkml.org 
[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: silent semantic changes with reiser4


On Tue, 31 Aug 2004, Horst von Brand wrote:
>
> You do need extra tools anyway, placing them in the kernel is cheating (and
> absolutely pointless, IMHO).

I agree.

There's no point to having the kernel export information that is already
inherent in the main stream.

I've seen all these examples of exposing MP3 ID information as a "side
stream", and that's TOTALLY POINTLESS! The information is already there,
it's in a standard format, and exporting it as a stream buys you
absolutely nothing.

Where named attributes make sense is when they are _independent_ data.
Data that is only tangentially related to the main stream itself, and
which the main stream _cannot_ encompass because of some real technical
issue.

In a graphical environment, the "icon" stream is a good example of this.
It literally has _nothing_ to do with the data in the main stream. The
only linkage is a totally non-technical one, where the user wanted to
associate a secondary stream with the main stream _without_ altering the
main one. THAT is where named streams make sense.

But if you want to look at one particular file inside a tar-file, do so in
user space. There are zero advantages to exposing it as a side-stream, and
there are absolutely _tons_ of disadvantages.

In short, named streams only make sense if:
- they are tied to the file some way that is _independent_ of the file
contents (since if it's dependent on the file contents, you're just a
ton better off regenerating it with a caching server)
- there are serious reasons to keep the lookup synchronized (since if
there isn't such a reason, you're just better off with a separate
shadow tree in user space)

And realize that the "separate shadow tree" actually works very well.
That's how version control systems like CVS have always worked. It's
certainly how you can make icon information work too. If you use a tool
for accessing the data, the tool can maintain coherency and you'll never
care about the side stream.

Which means that normally we really don't _want_ named streams. In 99% of
all cases we can use equally good - and _much_ simpler - tool-based
solutions.

Which means that the only _real_ technical issue for supporting named
streams really ends up being things like samba, which want named streams
just because the work they do fundamentally is about them, for externally
dictated reasons. Doing named streams for any other reason is likely just
being stupid.

Once you do decide that you have to do named streams, you might then
decide to use them for convenient things like icons. But it should very
much be a secondary issue at that point.

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

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.667 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site