From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Dec 2001 13:25:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Dec 2001 13:25:24 -0500 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:1176 "EHLO vindaloo.ras.ucalgary.ca") by vger.kernel.org with ESMTP id ; Mon, 10 Dec 2001 13:24:26 -0500 Date: Mon, 10 Dec 2001 11:24:21 -0700 Message-Id: <200112101824.fBAIOLJ22603@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Alexander Viro Cc: Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: [RFC] devfs=only and boot In-Reply-To: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alexander Viro writes: > Richard, just how devfs=only is supposed to work with > loading ramdisk from floppies? IIRC, it's supposed to work just like normal reading from a floppy. That should still work. > BTW, with initrd exiting with real-root-dev set (regardless of > devfs=only) your code still goes by root_device_name and ignores new > ROOT_DEV. Again, what behaviour is expected? The intent is that root_device_name is changed, so it should just work. Has something broken? AFAIK, this too used to work. I'll try to have a closer look at this tonight. Which kernel version are you staring at? BTW: you didn't respond to my question about fixing devfs+blkdev races. If my scheme will work, or at least improve things, I'd like to include that in my next patch. Marcelo is waiting for me to fix something else. Here's what I wrote a couple of days ago: Alexander Viro writes: > BTW, here's one more devfs rmmod race: check_disk_changed() in > fs/devfs/base.c. Calling ->check_media_change() with no protection > whatsoever. If rmmod happens at that point... How about if I do this sequence: lock_kernel(); devfs checks; if (bd_op->owner) __MOD_INC_USE_COUNT(bd_op->owner); revalidate(); if (bd_op->owner) __MOD_DEC_USE_COUNT(bd_op->owner); unlock_kernel(); Is there any reason why that won't work? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca