From mboxrd@z Thu Jan 1 00:00:00 1970 From: mjt@nysv.org (Markus =?ISO-8859-1?Q?=20T=F6rnqvist?=) Subject: Re: silent semantic changes with reiser4 Date: Wed, 1 Sep 2004 22:44:45 +0300 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040901194445.GM26192@nysv.org> References: <200408311931.i7VJV8kt028102@laptop11.inf.utfsm.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Horst von Brand , Pavel Machek , David Masover , Jamie Lokier , Chris Wedgwood , viro@parcelfarce.linux.theplanet.co.uk, Christoph Hellwig , Hans Reiser , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Lyamin aka FLX , ReiserFS List Return-path: Received: from nysv.org ([213.157.66.145]:44939 "EHLO nysv.org") by vger.kernel.org with ESMTP id S267447AbUIATo4 (ORCPT ); Wed, 1 Sep 2004 15:44:56 -0400 To: Linus Torvalds Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org On Tue, Aug 31, 2004 at 01:05:40PM -0700, Linus Torvalds wrote: > >There's no point to having the kernel export information that is already >inherent in the main stream. As said before, it can be bounced :) You have support for streams, someone could read the inherent information and write it to the stream. At the risk of these two streams being unsynced temporarily, requiring some syncer. >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, No it's not pointless :) >it's in a standard format, and exporting it as a stream buys you >absolutely nothing. There is no nice standard way of finding MP3s by the ID information. find music/ -name *mp3/..metas/id3/ | xargs grep -i "dream theater" or something. Which reveals the metadata to find. The kernel doesn't have to parse the ID3 tags, that can be handled in userspace by a daemon, updated based on mtimes or somesuch, yes? >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. Sure, when someone goes through every application from ls to nautilus and rams a tool-based patch down the app maintainer's throat and then we're still dependent on the filesystem layout, which is easier to break than the filesystem itself :) >Which means that the only _real_ technical issue for supporting named >streams really ends up being things like samba, which want named streams So they should be implemented for samba and other guys can come up with alternative means for using them ;) -- mjt