Ian Kent wrote: > Jeff Moyer wrote: >> Ian Kent <raven@xxxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
