Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268160AbUIFPoi (ORCPT ); Mon, 6 Sep 2004 11:44:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268159AbUIFPoi (ORCPT ); Mon, 6 Sep 2004 11:44:38 -0400 Received: from as8-6-1.ens.s.bonet.se ([217.215.92.25]:9938 "EHLO zoo.weinigel.se") by vger.kernel.org with ESMTP id S268156AbUIFPo3 (ORCPT ); Mon, 6 Sep 2004 11:44:29 -0400 To: Spam Cc: Christer Weinigel , Pavel Machek , Tonnerre , Linus Torvalds , Horst von Brand , David Masover , Jamie Lokier , Chris Wedgwood , , Christoph Hellwig , Hans Reiser , , , Alexander Lyamin aka FLX , ReiserFS List Subject: Re: silent semantic changes with reiser4 References: <200408311931.i7VJV8kt028102@laptop11.inf.utfsm.cl> <20040905111743.GC26560@thundrix.ch> <1215700165.20040905135749@tnonline.net> <20040905115854.GH26560@thundrix.ch> <1819110960.20040905143012@tnonline.net> <20040906105018.GB28111@atrey.karlin.mff.cuni.cz> <6010544610.20040906143222@tnonline.net> <826067315.20040906171320@tnonline.net> From: Christer Weinigel Organization: Weinigel Ingenjorsbyra AB Date: 06 Sep 2004 17:44:28 +0200 In-Reply-To: <826067315.20040906171320@tnonline.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4140 Lines: 80 Spam writes: > > When you add a new shared namespace, userspace must be taught about it > > anyways. So start with a userspace library, convince people to use > > it, and when you know what people want, _then_ put it into the kernel > > to increase performance or security. > > Several aspects of this; > > 1) Programs will need to actually be coded against this shared > library which probably will be more advanced that just usning normal > file access code. Not at all. As many others have already shown, trying to use files as directories won't work since then you can't have named streams or attributes for real directories. What does foo/icon refer to when foo is a directory? There must be some way of differentiating between them, which in turn means that we need a new way of referring to the stream. So the simple, hackish, solution really won't fly. Besides, it will probably break a lot of security critical assumptions in todays software. What if you have a filter in your web server that excludes executable files or files that end with .php, can you imagine the mess if you could just open "foo.php/main-stream" instead? > 2) Then we redo it all again to fit in the kernel, as a kernel > plugin or user-level plugin. No, we use the same user space library, but let the user space library use helper functions in the kernel. We could for example add a function that opens a named stream based on a filename which uses a .xattr directory in the same directory as the file, or in database in our home directory. If we add a solaris-like openat(3) syscall we modify the library to take advantage of it. > Plugins were just another thing that could extend the functionality > of these streams and meta data. Reiser4 has a plugin architecture, > although not yet any run-time support for loading them. Is this so > bad that we have to prevent it? Take an example: "expose a tar-file as streams below the file" which as been suggested here is IMNSHO plain silly. I'm not saying anything about mounting a tar file via userfs somewhere else in the file system, that is quite ok, but trying to mount it on top of the same file which suddenly and automagically turns into a sort-of-directory breaks too many thing. Let your file manager do the choice instead, based on the users preferences. For example, with a tar.gz-file, I'd like to have a choice of "open file as a seekable file" which would do: mount -t userfs -o driver=gunzip foo.tar.gz /tmp/xyzzy Then I can work with /tmp/xyzzy as a normal file (maybe even with write access if the userfs driver can handle this). Another choice in the same file manager would be "open file as a directory" which would mount the same file in _another place_ as a directory, and I can even have different views of the same file mounted at the same time. With the named streams junk that have been suggested here, having two different views would be impossible. Sure, we could say that we add another level of indirection to the named streams, so that we specify the driver as the first component of te magic file-as-directory, i.e. foo.tar.gz/ungzipped would refer to the ungzipped stream and foo.tar.gz/ungzipped-and-untarred would show the tar file as a directory, but really, this isn't any more useful than doing a userfs mount. The userfs mount does not break existing semantics (anymore than mount -o loop does today), and it will work with the existing infrastructure in the linux kernel. The only advantage of files-as-directories with magic plugins in the kernel is that one can look at it and say "look, how neat, the filenames look almost the same". /Christer -- "Just how much can I get away with and still go to heaven?" Freelance consultant specializing in device driver programming for Linux Christer Weinigel http://www.weinigel.se - 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/