Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268275AbUIFQIW (ORCPT ); Mon, 6 Sep 2004 12:08:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268274AbUIFQIV (ORCPT ); Mon, 6 Sep 2004 12:08:21 -0400 Received: from as8-6-1.ens.s.bonet.se ([217.215.92.25]:26578 "EHLO zoo.weinigel.se") by vger.kernel.org with ESMTP id S268253AbUIFQIB (ORCPT ); Mon, 6 Sep 2004 12:08:01 -0400 To: Pavel Machek Cc: Christer Weinigel , Spam , Tonnerre , Linus Torvalds , Horst von Brand , 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 Subject: Re: silent semantic changes with reiser4 References: <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> <20040906155456.GC13539@atrey.karlin.mff.cuni.cz> From: Christer Weinigel Organization: Weinigel Ingenjorsbyra AB Date: 06 Sep 2004 18:07:58 +0200 In-Reply-To: <20040906155456.GC13539@atrey.karlin.mff.cuni.cz> 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: 1451 Lines: 30 Pavel Machek writes: > Who is going to umount it when application crashes, etc? Who removes temporary files left behind when an application crashes? I'd guess a daemon such as autofs could do a very good job here. >Plus mount required root priviledges last time I checked. bash$ ls -l /bin/mount -rwsr-xr-x 1 root root 78504 May 4 23:34 /bin/mount with proper policies in userspace it allows users to perform mounts. I'm not suggesting that the kernel should be unchanged, but really, some of the proposals here, to put a hell of a lot of complexity into the kernel it just wet dreams with not much thought of how it affects the kernel. What happened to the philosophy of putting complexity and policy in userspace? Look at khttpd and tux, they were hacks in the kernel to try things out. But what ended up in the kernel is generic infrastructure that is useful for a lot more applications than just a web server. That is the right way to do things. /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/