linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steve French <smfrench@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, CIFS <linux-cifs@vger.kernel.org>
Subject: Re: [GIT PULL] cifs/smb3 client fixes
Date: Tue, 31 Aug 2021 10:43:29 -0700	[thread overview]
Message-ID: <CAHk-=wjxmDks6CS41PCy_BZG70pjAhcPBV_7ga8kSJySvvDezQ@mail.gmail.com> (raw)
In-Reply-To: <CAH2r5mtTLUQa2U=MGHOVk_FsPZg6owMsw+RoTudWxGuoQej41g@mail.gmail.com>

On Tue, Aug 31, 2021 at 10:09 AM Steve French <smfrench@gmail.com> wrote:
>
>   So if you are ok with renaming the client dir and module
> name - we can gradually stop using the word/name "cifs" except for the
> parts of code which really are needed to access the (unfortunately
> hundreds of millions of) very old devices which require SMB1 ("CIFS").

I'm ok with directory renames, git handles it all well enough that the
pain should be fairly minimal.

I'd ask for that to be done during a fairly calm cycle, though, when
there isn't a lot pending, so that any rename conflicts will be
minimized.

> We could even build two versions of the module "smb3.ko" which does not
> include support for the less secure legacy dialects and "cifs.ko" which does
> include it.   Is there a precedent for something similar.

I'm not sure there is precedent for that, but that's not a huge issue per se.

Whether it's actually worth it having two separate modules, I don't know.

That said, I'm not entirely enamoured with the name "smb" as a module
(or directory) name, to put it lightly.

Part of it is that it can mean "system management bus" too, although
in the kernel we happily universally (?) use "smbus" for that.

But a big part of it is exactly the history of random different names,
which means that I'd like any new name to be more explicit than a TLA
that has been mis-used for so long.

So yes, we have "fs/nfs/", but I'd rather _not_ have "fs/smb/".

They may superficially look entirely equivalent - but one of them has
had a consistent name that is unambiguous and has no horrible naming
history. The other has not.

> Do you have any objections to me renaming the client's source
> directory to "fs/smb3" (or fs/smb) and fs/smb3_common ...?

So no objections to the rename per se, but can we please use a more
specific name that is *not* tainted by history?

I'll throw out two suggestions, but they are just that: (a) "smbfs" or
(b) "smb-client".

I think "smbfs" has the nice property of making it clear that this is
just the filesystem part of the smb protocols - that otherwise cover a
lot of other things too (at least historically printers, although I
have no idea how true that is any more).

And "smb-client" as a name is in no way great, but at least it's not
just a TLA, and from a naming standpoint it would match the
"smb-common" thing (although I guess you used an underscore, not a
dash).

Again - those are just two random suggestions, and I'm not married to
either of them, I just really don't like just that "smb" because of
all the historical naming baggage.

So if we rename, we should rename it to something new and slightly
more specific than what we used to have.

I'd rather have a module called "smbfs.ko" (or "smb-fs.ko" or
"smb-client.ko" etc) than "smb.ko".

And no, I wouldn't want it to be called "smb3" either. Because it
clearly does cifs/smb1 and smb2 too (even if people would obviously
like to deprecate at least the older parts).

Hmm? Is there some unambiguous name that is in use by the smb
community and would work?

                 Linus

  reply	other threads:[~2021-08-31 17:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30  5:48 Steve French
2021-08-31 16:39 ` Linus Torvalds
2021-08-31 17:08   ` Steve French
2021-08-31 17:43     ` Linus Torvalds [this message]
2021-08-31 18:06       ` Steve French
2021-09-14 21:21         ` Steve French
2021-09-13 16:19       ` Fwd: " Steve French
2021-08-31 16:41 ` pr-tracker-bot
2021-09-18 19:54 Steve French
2021-09-20 23:32 ` pr-tracker-bot
2021-09-24 23:23 Steve French
2021-09-25 19:06 ` pr-tracker-bot
2021-11-06 13:49 Steve French
2021-11-06 23:50 ` pr-tracker-bot
2021-12-10 20:41 Steve French
2021-12-11  1:38 ` pr-tracker-bot
2022-02-04  6:08 Steve French
2022-02-04 17:58 ` pr-tracker-bot

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='CAHk-=wjxmDks6CS41PCy_BZG70pjAhcPBV_7ga8kSJySvvDezQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@gmail.com \
    --subject='Re: [GIT PULL] cifs/smb3 client fixes' \
    /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

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