linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
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 13:06:41 -0500	[thread overview]
Message-ID: <CAH2r5mt72NYan9q8MR5H8cNkYzT4jn1ZM1f3jp5V-fDs2cyB-A@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjxmDks6CS41PCy_BZG70pjAhcPBV_7ga8kSJySvvDezQ@mail.gmail.com>

On Tue, Aug 31, 2021 at 12:43 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> 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.

Given likely movement of various common server/client functions into
cifs_common in the short term - we can delay renaming "fs/cifs"
(and fs/cifs_common) to e.g. "fs/smbfs" to 5.16 or 5.17


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

<snip>

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

"smbfs" would likely be fine and I can bounce the idea around
others on Samba team etc.  And yes you are right, the broader
"SMB family of protocols" covers a lot of other functions
(from systems management, DCE/RPC, clustering, change notification,
named pipes, global name space ... not just files and printers) so "smbfs"
as a name for the client fs module going forward may be a bit less confusing.

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

That should be easy enough (IIRC FreeBSD called their
module "smbfs), but presumably wait until 5.16 or 5.17
to lessen merge conflicts etc.


-- 
Thanks,

Steve

  reply	other threads:[~2021-08-31 18:06 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
2021-08-31 18:06       ` Steve French [this message]
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=CAH2r5mt72NYan9q8MR5H8cNkYzT4jn1ZM1f3jp5V-fDs2cyB-A@mail.gmail.com \
    --to=smfrench@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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).