The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: ChenXiaoSong <chenxiaosong.chenxiaosong@linux.dev>
To: Steve French <smfrench@gmail.com>
Cc: Namjae Jeon <linkinjeon@kernel.org>,
	sfrench@samba.org, linkinjeon@samba.org,
	linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org,
	chenxiaosong@chenxiaosong.com,
	ChenXiaoSong <chenxiaosong@kylinos.cn>
Subject: Re: [PATCH 09/10] smb: create common/common.h and common/common.c
Date: Fri, 5 Dec 2025 09:44:05 +0800	[thread overview]
Message-ID: <7eac3a36-d2a2-400f-a4a2-7cec245a2709@linux.dev> (raw)
In-Reply-To: <CAH2r5mv74OszZ610pTn+vZq3ubRdx=+au=SHRNFpyt2rigKkYQ@mail.gmail.com>

Now, where should common/smb2maperror.c go? Should it be built into both 
cifs.ko and ksmbd.ko?

Thanks,
ChenXiaoSong.

On 12/5/25 09:36, Steve French wrote:
> i lean against an 'smbcommon.ko'   - it can be helpful to move common
> code (headers, #defines etc) into fs/smb/common but other than
> smbdirect code (where smbdirect.ko makes sense for cifs.ko, ksmbd.ko,
> Samba and user space AI apps e.g. to use), I lean against creating new
> modules for the client and server.
> 
> ksmbd.ko for server code
> cifs.ko (or maybe someday renamed to smb3.ko) for client code
> smbdirect.ko for the RDMA/smbdirect code shared by ksmbd/cifs.ko/userspace tools
> 
> maybe (as they did for the md4 code creating an cifs_md4.ko so that
> less secure code doesn't have to be linked in if unneeded) someday we
> could split an "smb1.ko" out for the SMB1 related code (since we want
> to discourage use of old insecure dialects, and could shrink cifs.ko,
> and slightly simplify it)
> 
> Finding common code is good - but let's not complicate things by
> creating lots of new modules - in the short term the focus is on
> sanely splitting the common RDMA/smbdirect code out (because 1) it is
> large enough 2) it will have use cases outside of cifs.ko and
> ksmbd.ko).  But I lean against creating multiple new modules in the
> short term.
> 
> On Thu, Dec 4, 2025 at 6:59 PM ChenXiaoSong
> <chenxiaosong.chenxiaosong@linux.dev> wrote:
>>
>> OK, I will create new smb2maperror.ko and will send v2 soon.
>>
>> Thanks for your review and suggestions.
>>
>> Thanks,
>> ChenXiaoSong.
>>
>> On 12/5/25 08:35, Namjae Jeon wrote:
>>> On Thu, Dec 4, 2025 at 2:00 PM <chenxiaosong.chenxiaosong@linux.dev> wrote:
>>>>
>>>> From: ChenXiaoSong <chenxiaosong@kylinos.cn>
>>>>
>>>> Preparation for moving client/smb2maperror.c to common/.
>>>>
>>>> We can put cifs_md4 and smb2maperror into a single smb_common.ko,
>>>> instead of creating two separate .ko (cifs_md4.ko and smb2maperror.ko).
>>> Sorry, I prefer not to create new *.ko for only smb2maperror.
>>>>
>>>>     - rename md4.h -> common.h, and update include guard
>>>>     - create common.c, and move module info from cifs_md4.c into common.c
>>> ksmbd does not use md4 in smb/common, I don't prefer this either.
>>> I would appreciate it if you could send me the patch set again except these.
>>>>
>>>> Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
>>
> 
> 


  reply	other threads:[~2025-12-05  1:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-04  4:58 [PATCH 00/10] smb: improve search speed of SMB2 maperror chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 01/10] smb/client: reduce loop count in map_smb2_to_linux_error() by half chenxiaosong.chenxiaosong
2025-12-04  5:49   ` Steve French
2025-12-04  5:55     ` ChenXiaoSong
2025-12-04  4:58 ` [PATCH 02/10] smb/client: remove unused elements from smb2_error_map_table array chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 03/10] smb: add two elements to " chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 04/10] smb/client: sort " chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 05/10] smb/client: use bsearch() to find target status code chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 06/10] smb/client: introduce smb2_get_err_map() chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 07/10] smb/client: introduce smb2maperror KUnit tests chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 08/10] smb/server: rename include guard in smb_common.h chenxiaosong.chenxiaosong
2025-12-04  4:58 ` [PATCH 09/10] smb: create common/common.h and common/common.c chenxiaosong.chenxiaosong
2025-12-05  0:35   ` Namjae Jeon
2025-12-05  0:58     ` ChenXiaoSong
2025-12-05  1:36       ` Steve French
2025-12-05  1:44         ` ChenXiaoSong [this message]
2025-12-05  1:50           ` Steve French
2025-12-05  2:14             ` ChenXiaoSong
2025-12-05  3:02               ` ChenXiaoSong
2025-12-04  4:58 ` [PATCH 10/10] smb: move client/smb2maperror.c to common/ chenxiaosong.chenxiaosong
2025-12-04 20:39   ` kernel test robot
2025-12-04 21:12   ` kernel test robot
2025-12-05  2:35   ` kernel test robot

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=7eac3a36-d2a2-400f-a4a2-7cec245a2709@linux.dev \
    --to=chenxiaosong.chenxiaosong@linux.dev \
    --cc=chenxiaosong@chenxiaosong.com \
    --cc=chenxiaosong@kylinos.cn \
    --cc=linkinjeon@kernel.org \
    --cc=linkinjeon@samba.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfrench@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox