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>
>>
>
>
next prev parent 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