From: Enzo Matsumiya <ematsumiya@suse.de>
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-cifs@vger.kernel.org, smfrench@gmail.com, pc@cjr.nz,
ronniesahlberg@gmail.com, nspmangalore@gmail.com,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tom@talpey.com, samba-technical@lists.samba.org,
pshilovsky@samba.org
Subject: Re: [RFC PATCH 0/3] Rename "cifs" module to "smbfs"
Date: Wed, 3 Aug 2022 11:45:19 -0300 [thread overview]
Message-ID: <20220803144519.rn6ybbroedgmuaie@cyberdelia> (raw)
In-Reply-To: <6f3479265b446d180d71832fd0c12650b908ebe2.camel@kernel.org>
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
next prev parent reply other threads:[~2022-08-03 14:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 19:09 [RFC PATCH 0/3] Rename "cifs" module to "smbfs" Enzo Matsumiya
2022-08-01 19:09 ` [RFC PATCH 1/3] cifs: change module name to "smbfs.ko" Enzo Matsumiya
2023-07-26 20:28 ` Steve French
2023-07-26 20:29 ` Steve French
2023-07-26 20:31 ` Steve French
2023-07-27 0:24 ` Enzo Matsumiya
2022-08-01 19:09 ` [RFC PATCH 2/3] smbfs: rename directory "fs/cifs" -> "fs/smbfs" Enzo Matsumiya
2022-08-01 19:09 ` [RFC PATCH 3/3] smbfs: update doc references Enzo Matsumiya
2022-08-02 14:42 ` [RFC PATCH 0/3] Rename "cifs" module to "smbfs" Jeff Layton
2022-08-02 19:36 ` Enzo Matsumiya
2022-08-02 20:07 ` Jeff Layton
2022-08-03 1:32 ` Tom Talpey
2022-08-03 1:56 ` Enzo Matsumiya
2022-08-04 19:03 ` Jeff Layton
2022-08-04 20:23 ` Matthew Wilcox
2022-08-04 20:48 ` Jeff Layton
2022-08-03 5:38 ` Steve French
2022-08-03 14:45 ` Enzo Matsumiya [this message]
2022-08-03 17:50 ` Paulo Alcantara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220803144519.rn6ybbroedgmuaie@cyberdelia \
--to=ematsumiya@suse.de \
--cc=jlayton@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nspmangalore@gmail.com \
--cc=pc@cjr.nz \
--cc=pshilovsky@samba.org \
--cc=ronniesahlberg@gmail.com \
--cc=samba-technical@lists.samba.org \
--cc=smfrench@gmail.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).