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. > > 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
