Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750962AbWBSUEt (ORCPT ); Sun, 19 Feb 2006 15:04:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750964AbWBSUEt (ORCPT ); Sun, 19 Feb 2006 15:04:49 -0500 Received: from smtp.osdl.org ([65.172.181.4]:21421 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1750959AbWBSUEs (ORCPT ); Sun, 19 Feb 2006 15:04:48 -0500 Date: Sun, 19 Feb 2006 12:02:21 -0800 From: Andrew Morton To: Alan Stern Cc: psusi@cfl.rr.com, pavel@suse.cz, torvalds@osdl.org, mrmacman_g4@mac.com, alon.barlev@gmail.com, linux-kernel@vger.kernel.org, linux-pm@lists.osdl.org Subject: Re: Flames over -- Re: Which is simpler? Message-Id: <20060219120221.1d11cee0.akpm@osdl.org> In-Reply-To: References: <43F89F55.5070808@cfl.rr.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2905 Lines: 61 Alan Stern wrote: > > On Sun, 19 Feb 2006, Phillip Susi wrote: > > > Andrew Morton wrote: > > >> > > >> Hrm... interesting but sounds like that could be sticky. For instance, > > >> what if the user script that does the verifying happens to be ON the > > >> volume to be verified? > > > > > > Well that would be a bug. Solutions would be a) don't put the scripts on a > > > removable/power-downable device or b) use tmpfs. > > > > > > > I don't see how it could be a bug, just think of the root on usb case. > > Keeping the program locked in ram would sidestep that issue, but tmpfs > > is pagable right? Swap on usb? > > > > Also, this user space program isn't going to be able to keep fully up to > > date on what the disk looks like. Imagine a filesystem that keeps a > > generation counter in the super block and increments it every time it > > writes to the disk. The user space daemon might read that, then the fs > > changes it, you suspend, and when you wake up, the daemon thinks the > > media changed because it wasn't fully up to date. > > There are other, harder problems associated with doing this is userspace. > > Really, the device needs to be considered separately at each level of > driver processing. At the USB level it may still appear to be the same, > but at the SCSI level it may appear different. Or at the SCSI level it > may be the same, but at the gendisk level it may be different (different > media, partition table changed). Or at the gendisk level it may be the > same, but at the filesystem level one or more of the partitions may be > different (superblock changed). > > Each level would need its own way of checking for changes and recreating > the appropriate data structures. And while making the determinations, we > would need to temporarily set the device to read-only. Yes, userspace > could do _some_ of the work, but it would need a lot of help from the > kernel. > There are two things here: a) identifying the device and b) putting it into the correct place in the various data structures. I suspect these can (and should) be separated out. For a), the current kernel behaviour is what we want - make the thing appear at a new place in the namespace and in the hierarchy. Then userspace can do whatever needs to be done to identify the device, and apply some sort of policy decision to the result. It's what comes next that we're missing: the ability for userspace to tell the krnrel what the decice's naming and positioning _should_ be. The kernel will then atomically tear down what it currently has and will then set everything up as desired. - 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/