Re: [PATCH 1/2] vfs: make real_lookup do dentry revalidation with

[Ian Kent <raven@themaw.net>]

Ian Kent wrote:
> Jeff Moyer wrote:
>> Ian Kent <raven@themaw.net> 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
>