On 08/02, Jeff Layton wrote:
If the concern is "branding" then I don't see how this really helps. Very few users interact with the kernel modules directly. FWIW, I just called "modprobe smb3" on my workstation and got this: [ 1223.581583] Key type cifs.spnego registered [ 1223.582523] Key type cifs.idmap registered [ 1230.411422] Key type cifs.idmap unregistered [ 1230.412542] Key type cifs.spnego unregistered Are you going to rename the keyrings too? That will have implications for userland helper programs like cifs.upcall. There's also /proc/fs/cifs/*. These are a "stable interfaces" that you can't just rename at will. If you want to change these interfaces then you need to do a formal deprecation announcement, and probably a period with /proc/fs/smbfs and /proc/fs/cifs coexisting. There are also a ton of printk's and such that have "CIFS" in them that will need to be changed. These costs do not seem worth the perceived benefit to me. You could probably hide a lot of what users see by just renaming (or symlinking) mount.cifs to mount.smb3. I think if you guys are serious about this, you should probably start somewhere else besides renaming the directory and module. This is going to impact developers (and people who make their living doing backports) far more than it will users.
I was thinking about the possible issues of a rename, and my perspective/assessment of the impact is this: For devs: - from running userspace/upcall tools with "cifs" name for a while until everything eventually catches up - not much else, really (enlighten me here please) For backporters/distros: - this might *look* like an issue first, because of the name conflicts it would arise when backporting fixes to older kernels, but these are _just_ a rename, without any functional changes whatsoever. It could be backported just fine as well, and customers/end users would still see no difference in behaviour For customers/end users: - at first, there should be no impact. "cifs" and "smb3" modules aliases are kept (and will be for a long while) and nothing else changes (procfs entry, idmap/spnego upcalls, mount.cifs, etc stays the same) A note on backports: I myself (and Paulo) do the backports for our SLE products, sometimes down to SLE11-SP4 (based on kernel 3.0) and I could not see what other issues could appear given if we backport this rename to released products. Of course, I don't know every process for every distro vendors, so if someone could provide feedback on this, I'd appreciate. @Paulo I'd like to hear your opinion on possible issues of future backports, if we backported this rename patch to SLES. Cheers, Enzo
