All of lore.kernel.org
 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 09:39:42 -0700	[thread overview]
Message-ID: <CAHk-=wiNvB_j3VZYJ1yZqq+9JjgWCO1MUmRsjTKBwQ+x=kB5tg@mail.gmail.com> (raw)
In-Reply-To: <CAH2r5mvVdBoUW-0BfsxiRAE6X30cqhBtNDvG7pwKdQwsu+wXfg@mail.gmail.com>

On Sun, Aug 29, 2021 at 10:48 PM Steve French <smfrench@gmail.com> wrote:
>
> - mostly restructuring to allow disabling less secure algorithms (this
> will allow eventual removing rc4 and md4 from general use in the
> kernel)

Well, you should probably have mentioned that you already started on
this by removing LANMAN support.

I'm sincerely hoping nobody used or depended on that old garbage in
this day and age any more.

Anyway, entirely unrelated question: you pretty much interchangeably
use "cifs" or "smb3" for the filesystem, as shown once more by the
commit messages here (but also the subject line).

The filesystem directory is called "cifs", and I've taken to use that
in my "Pull cifs updates" thing from you to just avoiding the
confusion.

And now we have ksmbd (yup, I just merged that pull request too), so
we have a "cifs client" and a "smb server". Aaarrgh.

I understand that some people may care about the name, may care about
"smb2 vs smb3", or whatever. But I have to admit finding it a bit
annoying how the code and the directory layout uses these different
terms pretty much randomly with no real apparent logic.

Somehow the NFS people had no problem completely changing everything
about their protocols and then still calling the end result "nfs
client" vs "nfs server".

Oh well. I'm assuming it's not going to change, and it's not really a
problem, I just wanted to mention my frustration about how clear as
mud the naming is.

             Linus

  reply	other threads:[~2021-08-31 16:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30  5:48 [GIT PULL] cifs/smb3 client fixes Steve French
2021-08-31 16:39 ` Linus Torvalds [this message]
2021-08-31 17:08   ` Steve French
2021-08-31 17:43     ` Linus Torvalds
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
2023-03-26  2:02 Steve French
2023-03-26 16:21 ` 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-=wiNvB_j3VZYJ1yZqq+9JjgWCO1MUmRsjTKBwQ+x=kB5tg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.