On 08/02, Jeff Layton wrote:
On Mon, 2022-08-01 at 16:09 -0300, Enzo Matsumiya wrote:
Hi,
As part of the ongoing effort to remove the "cifs" nomenclature from the
Linux SMB client, I'm proposing the rename of the module to "smbfs".
As it's widely known, CIFS is associated to SMB1.0, which, in turn, is
associated with the security issues it presented in the past. Using
"SMBFS" makes clear what's the protocol in use for outsiders, but also
unties it from any particular protocol version. It also fits in the
already existing "fs/smbfs_common" and "fs/ksmbd" naming scheme.
This short patch series only changes directory names and includes/ifdefs in
headers and source code, and updates docs to reflect the rename. Other
than that, no source code/functionality is modified (WIP though).
Patch 1/3: effectively changes the module name to "smbfs" and create a
"cifs" module alias to maintain compatibility (a warning
should be added to indicate the complete removal/isolation of
CIFS/SMB1.0 code).
Patch 2/3: rename the source-code directory to align with the new module
name
Patch 3/3: update documentation references to "fs/cifs" or "cifs.ko" or
"cifs module" to use the new name
Enzo Matsumiya (3):
cifs: change module name to "smbfs.ko"
smbfs: rename directory "fs/cifs" -> "fs/smbfs"
smbfs: update doc references
...
Why do this? My inclination is to say NAK here.
This seems like a lot of change for not a lot of benefit. Renaming the
directory like this pretty much guarantees that backporting patches
after this change to kernels that existed before it will be very
difficult.
Hi Jeff, yes that's a big concern that I've discussed internally with my
team as well, since we'll also suffer from those future backports.
But, as stated in the commit message, and from what I gathered from
Steve, it has been an ongoing wish to have the "cifs" name no longer
associated with a module handling SMB2.0 and SMB3.0, as the name brings
back old bad memories for several users.
There really is no functional benefit for this change, and I have no
argument against that.
Also, bear in mind that there used to be an smbfs in the kernel that
predated cifs.ko. That was removed ~2010 though, which is long enough
ago that it shouldn't produce conflicts in currently shipping releases.
Yes, I was aware of this before sending v1, and it got raised again in
https://lore.kernel.org/all/20220802135201.4vm36drd5mp57nvv@cyberdelia/
I have no experience on what kind of issues/problems could arise of
that, aside from the git commit history being weird. If you ever seen
any problems with that happening, please do share.
Jeff Layton <jlayton@xxxxxxxxxx>
I sent a v2 with a new "fs/smb" directory name, but kept "smbfs" as the
module name.
Sorry I didn't reply to you before that, I got confused as the thread
replies all went to different folders in my mailbox.
Cheers,
Enzo
