Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAH2r5mvVdBoUW-0BfsxiRAE6X30cqhBtNDvG7pwKdQwsu+wXfg@mail.gmail.com>
 <CAHk-=wiNvB_j3VZYJ1yZqq+9JjgWCO1MUmRsjTKBwQ+x=kB5tg@mail.gmail.com>
 <CAH2r5mtTLUQa2U=MGHOVk_FsPZg6owMsw+RoTudWxGuoQej41g@mail.gmail.com> <CAHk-=wjxmDks6CS41PCy_BZG70pjAhcPBV_7ga8kSJySvvDezQ@mail.gmail.com>
In-Reply-To: <CAHk-=wjxmDks6CS41PCy_BZG70pjAhcPBV_7ga8kSJySvvDezQ@mail.gmail.com>
From:   Steve French <smfrench@gmail.com>
Date:   Tue, 31 Aug 2021 13:06:41 -0500
Message-ID: <CAH2r5mt72NYan9q8MR5H8cNkYzT4jn1ZM1f3jp5V-fDs2cyB-A@mail.gmail.com>
Subject: Re: [GIT PULL] cifs/smb3 client fixes
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        CIFS <linux-cifs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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