From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: [PATCH 1/2] vfs: make real_lookup do dentry revalidation with Date: Wed, 14 Oct 2009 10:57:45 +0800 Message-ID: <4AD53E29.4070807@themaw.net> References: <20090923232844.GA22153@llnl.gov> <4ABAEC9F.4020607@themaw.net> <20090924070051.GL14381@ZenIV.linux.org.uk> <4ABB2178.3090500@themaw.net> <4ACC1360.9030007@themaw.net> <4AD538A4.9090609@themaw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Al Viro , Jim Garlick , "linux-fsdevel@vger.kernel.org >> linux-fsdevel" , Sage Weil , "H. Peter Anvin" , Christoph Hellwig , Andrew Morton To: Jeff Moyer Return-path: Received: from outbound.icp-qv1-irony-out4.iinet.net.au ([203.59.1.104]:9473 "EHLO outbound.icp-qv1-irony-out4.iinet.net.au" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1755925AbZJNC7H (ORCPT ); Tue, 13 Oct 2009 22:59:07 -0400 In-Reply-To: <4AD538A4.9090609@themaw.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Ian Kent wrote: > Jeff Moyer wrote: >> Ian Kent writes: >>> I still need to deal with the autofs module. >>> >>> I'm reluctant to remove it and do the rename at the same time the other >>> changes are going in. >>> >>> I thought a better idea would be to leave the autofs module in place for >>> the moment and change the Kconfig help message to describe what is going >>> to happen and alert users to the fact it won't work and also change all >>> the defconfig files that select autofs to select autofs4. >>> >>> Thoughts please? >> I think it's safe to remove fs/autofs. There's no sense in keeping >> around code that doesn't work, and we don't really fix bugs in autofs3 >> anyway. Heck, when was the last time you got a bug report for it? I >> haven't seen one in probably 5 years! > > Agreed, that's not really the issue, the sort of things below are the worry. Another thing that is a bit of a worry is, for the reasons above, we haven't actually tested usage with version 3 for a long time and there have been many changes since. > >> I'm not so sure what the implications are of renaming autofs4 to autofs. >> At the very least, the autofs init script itself tries to load the >> autofs4 kernel module. This would cause issues when updating a kernel, >> so it sounds like a bad idea to me. If there was a module alias causing >> autofs to load when autofs4 is requested on newer kernels, I guess that >> would be okay. But I think that sort of thing is managed by the >> userspace configuration. The other option, then, is to ship an autofs >> with an init script that knows which module to load. Then, after that's >> been in the wild for some time (a year?), make the switch. > > Clearly we can't account for people using absolute paths so that will > cause pain for some. > > Some time ago Christoph suggested registering both autofs and autofs4 > but I'm not sure about that since both modules have always only > registered autofs as the file system name. > > We can add a MODULE_ALIAS() to the module source but that doesn't > completely work, I think because the user space tools then don't get the > directory right. Changing the user space configuration is also > problematic because booting from a kernel with and without would require > a configuration change every time. > > The obvious simple solution would be to use symlinks to make the > directory and module appear to be present, set about a process of user > awareness and remove them after some pre-defined number of subsequent > releases but I'm not sure how that approach would be received? We could > even write a module stub that issues a warning message to syslog and > then loads the autofs module but I haven't tried that yet. > > Please, folks, some suggestions. > > Ian >