Messages in this thread |  | | Date | Wed, 3 Aug 2022 11:45:19 -0300 | From | Enzo Matsumiya <> | Subject | Re: [RFC PATCH 0/3] Rename "cifs" module to "smbfs" |
| |
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
|  |