|From:||Linus Torvalds <torvalds-AT-osdl.org>|
|To:||Horst von Brand <vonbrand-AT-inf.utfsm.cl>|
|Subject:||Re: silent semantic changes with reiser4|
|Date:||Tue, 31 Aug 2004 13:05:40 -0700 (PDT)|
|Cc:||Pavel Machek <pavel-AT-ucw.cz>, David Masover <ninja-AT-slaphack.com>, Jamie Lokier <jamie-AT-shareable.org>, Chris Wedgwood <cw-AT-f00f.org>, viro-AT-parcelfarce.linux.theplanet.co.uk, Christoph Hellwig <hch-AT-lst.de>, Hans Reiser <reiser-AT-namesys.com>, linux-fsdevel-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, Alexander Lyamin aka FLX <flx-AT-namesys.com>, ReiserFS List <reiserfs-list-AT-namesys.com>|
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 firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds